On Wed, 18 Jan 2012 14:11:16 -0500, Andrei Alexandrescu
<[email protected]> wrote:
On 1/18/12 12:04 PM, Steven Schveighoffer wrote:
On Wed, 18 Jan 2012 08:59:57 -0500, Andrei Alexandrescu
<[email protected]> wrote:
On 1/18/12 7:20 AM, Steven Schveighoffer wrote:
The only array-specific properties of an array that the compiler
should
worry about are ptr and length. Everything else should be a library
function.
Even ptr and length should be in the library. The slice structure
should be defined in object.d. The only business the compiler has is
to lower the T[] type syntax and the [ ... ] literal syntax to
.object.Slice!T and .object.slice(...) form, and to make sure that
typeof(T[]) is not struct (although factually it is).
That is debatable. The exact semantics of length are not repeatable in
the library, where a get is a simple field access, yet a set calls a
method. To achieve the same you would have to require -inline on the
compile line.
At that point, we have to say "what does it buy us". The function to set
the length is already a library function, which is changable outside the
compiler. What do we gain besides saying the language is purer?
1. Offer the runtime the possibility of tweaking the efficiency of the
abstraction
The runtime already implements the abstraction. All that the compiler
does special is glue the property to the function call.
2. Smaller and simpler compiler
Maybe relevant for new compilers.
3. Detecting design and implementation bugs in the language (we found a
lot while porting the associative arrays)
There is only one function to set length. It's not quite comparable to
the entire set of associative array functionality. Though as someone who
has mostly rewritten it, I can say it's not a trivial function, and may
still have bugs in it. However, I don't see changing the entity who glues
the property to the function is going to find bugs in the function.
4. Uniform built-in type behavior and user-defined type behavior, which
is a boon for generic code and generally for the language size and
understandability
This I agree with, it makes the language uniformly implemented, which
makes things simpler to understand/implement. But it already works, and
works rather well. This is my point, all we gain is being able to say the
language is simpler/purer.
As a related example, look at how simple and efficient byKey and byValue
are thanks to migrating hashes into the runtime.
Not to mention *possible* :)
-Steve
