[Issue 5348] Variable Length Arrays

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5348


Dmitry Olshansky <dmitry.olsh at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh at gmail.com


--- Comment #2 from Dmitry Olshansky <dmitry.olsh at gmail.com> 2011-01-03 05:18:26 PST ---
> > As stated in this proposal they are quite useless, e.g. they are easily
> > implemented via mixin with alloca.
>
> This is false, a mixin solution can't replace a VLA because:
> - The compiler knows what a VLA is, so it may copy it automatically (as it does with fixed-sized arrays) if you return a VLA from a function.

Introducing more magic then it's worth - one thing I really dislike about this
proposal. It doesn't solve anything at all, yet uglifies language. How would
function signature look like for function returning VLA? How it then interacts
with other array types? Is supposed to be a slice of stack? I guess, no. But
with alloca that's all :
Foo* ptr = cast(Foo*)alloca(len * Foo.sizeof);
Foo[] arr = ptr[0 .. len];//that's all, last time I asked Steven, I got the
answer that you can even append to it (which would reallocate on first append)

Making it mixin is little extra cost for an *unsafe* feature as it is.

> - vla_array.sizeof gives the correct answer
Small benefit since you now beforehand the size you passed to it, and can
create slice out of of it. Plus, what semnatics do you propouse for VLA's on
return - value type? How it fits the rest of language?
> - alloca() is not pure, while a function that uses VLA can be pure.
..but as defined VLAs subtly destroing nothrow property, and in general are
leaky abstraction.
> - The VLA syntax is nicer, it doesn't look like hack, this encourages their
> usage, and it doesn't require imports. And if you need a 2D variable length
> matrix, you don't need a different mixin, the VLA syntax supports multi
> dimensional arrays.
I might be wrong but matrices are usaully either small and fixed sized, or big
arbitrarily sized and require allocation anyways. IMO every special case
language feature should do something importantly useful to prove worthy.
>
>
> > Plus, what's the benefit in throwing exception on alloca failure, how
> > you suppose the user to handle this stackoverflow exception?
>
> The proposal says that an error too is OK:
> > When a VLA array is allocated the D compiler tests that there is enough free stack left, and otherwise throws a runtime exception/error (like stack overflow).

I don't care what proposal *stated* is OK, I care for the user of this feature,
would  he/she like exception he/she can't *handle* in any sensible way or some
other default mechanism? I'm not seeing VLA as much safer/better then alloca in
this regard (in the latter you at least have options if you are the author of
this piece of code).
>
> > I would
> > have expected a better design to provide an optional parameter to
> > fallback to GC or something ( like malloc(...) + scope(exit) free(...);
> > ) and that's indicates a library solution, of course.
>
> This is a possibility to keep in mind. But it makes the VLA implementation a
> bit more complex:
Again, this just shows how VLAs as stated are not getting anything good.
Library solution can be complex and have options, built-in on the contrary
should be clear and lightweight.
Slicing the result of alloca + some fallback on failure path is OK (at least it
has clear semantics, and explicit). 
> - in the current proposal the VLA is represented by just a length. If you add a
> fall-back mechanism then you need to keep a pointer too on the stack.
It's not _too_ but _instead_ of reserving stack space :)

> - If you return a VLA the code has to copy the data contents only if the VLA is
> allocated on the stack.
And I yet have to see how function's return type would be defined as VLA.
What's makes me sad is there is not a single thing about actually defining
anything e.g. semantics of copying, interaction with the rest of language.
It's all more about "kind cool to have that, something like that, you know..."
> - This semantics is different from the C99 one. So people that know C99 need to
> read about this difference and understand it, and C99 code ported to D probably
> needs to keep in account the difference.

We should ask C99 folks if there are lots of VLAs used at all.
Sorry for being too critical, but at very least the proposal needs a lot of
refinement on actual implementation.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------