<p dir="auto">We need a general purpose FFI that can call any C library, using either tcc or clang.</p>
<p dir="auto">Suggested interface:</p>
<p dir="auto">loadc("libpcre") # loads the C library, reading headers and all<br>
/* the namespace libpcre could be used to avoid naming clashes _/<br>
pcre_compile("foo\s_bar", PCRE_CASELESS, ...)</p>
<p dir="auto">Long conversation with Jeff. Part of the discussion was around structs. We concluded that the main goal here is maximum compatibility with C. A <code class="notranslate">struct</code> is similar to a composite type (which we discussed renaming to <code class="notranslate">class</code> instead of <code class="notranslate">type</code>) except that it has immediate value semantics:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="struct Foo
  bar::Int32
  baz::Int32
end

julia&gt; foo = Foo(1,2)
Foo(1,2)

julia&gt; foo2 = foo
Foo(1,2)

julia&gt; foo2.bar = 3
3

julia&gt; foo2
Foo(3,2)

julia&gt; foo
Foo(1,2)"><pre class="notranslate"><code class="notranslate">struct Foo
  bar::Int32
  baz::Int32
end

julia&gt; foo = Foo(1,2)
Foo(1,2)

julia&gt; foo2 = foo
Foo(1,2)

julia&gt; foo2.bar = 3
3

julia&gt; foo2
Foo(3,2)

julia&gt; foo
Foo(1,2)
</code></pre></div>
<p dir="auto">This is kind of like immutability but without not allowing anything. Types like <code class="notranslate">Rational</code> and <code class="notranslate">Complex</code> would be structs rather than classes. However, we don't go as far as preventing reaching in and changing a field value. If you want to do that, you can, but don't. It's rude. So we have immutability by convention.</p>
<p dir="auto">A couple more things about structs:</p>
<ul dir="auto">
<li>struct fields must be typed</li>
<li>struct fields can only be bits types, other struct types, or refs</li>
<li>a ref is a pointer to the data part of a bits types or a struct type</li>
</ul>
<p dir="auto">Think of <code class="notranslate">Ref</code> like a C pointer in a struct — and it can be passed to C as-is since it points to the actual data part. However, if you look at the word before what the pointer points to, it is a valid Julia object too, so you can program with it in Julia and then just pass it to C without having to change anything. This provides maximum compatibility with C code. You could even write a linked list struct type in Julia and then just pass it to C code and have the C code traverse the linked list without any problems. Having C code pass structures back to Julia is more of a problem, however. Maybe it's a one-way street.</p>
<p dir="auto">Structs are laid out exactly the way C lays them out; they can also be stored in concrete arrays without any tags, giving C compactness and efficiency. If you do <code class="notranslate">Array(Foo,n)</code> then it is initially just filled with junk like <code class="notranslate">Array(Int32,n)</code> would be. Structs are just plain old data. They can, however, have constructors.</p>
<p dir="auto">Some issues we haven't fully thought through are fixed-size array fields and struct unions. But we can worry about those later.</p>