On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu
wrote:
On 1/30/15 10:40 AM, Foo wrote:
On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven
wrote:
On 30/01/2015 16:53, Nick Treleaven wrote:
This version of staticArray allows the user to (optionally)
specify the
element type.
Actually, I'm having trouble implementing staticArray like
that,
perhaps there are compiler issues causing problems. Using
this:
T[len] staticArray(T, size_t len)(T[len] items)
{
return items;
}
you would need to call it: staticArray([a, b, c]). UFCS
doesn't seem
to work, and I can't get the immutable or function array
example to
compile either (with the extra [brackets])...
That is such a ugly call. Consider this:
----
@nogc
@safe
T[n] s(T, size_t n)(auto ref T[n] values) pure nothrow {
return values;
}
void main() {
pragma(msg, typeof([1, 2, 3].s));
}
----
Something like staticArray([1, 2, 3]) is probably so ugly and
way to
long so that nobody new would like it or use it. We should
consider the
usability. int[$] looks nicer and is shorter. Nobody want to
type ugly
and long names instead.
Let look at staticArray([1, 2, 3]) as a new user: "I have to
call a
function with an array(whereby it is unclear to the new user
if [1, 2,
3] is placed on the heap or not) and the result of this call
is a static
array? Why? Is it worth it? Should I use something cumbersome?"
That is why I'm either for the language feature or for
something short
like '[1, 2, 3].s'
And no, nobody want to write 'alias s = staticArray' every
time again.
Don't come with this counter please.
The interesting thing is because of the tight overloading
rules, "s" will only match statically-sized arrays. So it's
okay to simply expose it as std.array.s without fear it might
clash with other uses of the "s" symbol. Awesome. -- Andrei
Exactly. ;)
