On Mon, Oct 15, 2012 at 07:05:13PM +0200, Simen Kjaeraas wrote:
> On 2012-35-15 17:10, Namespace <rswhi...@googlemail.com> wrote:
>
> >But bar([1, 2, 3]); not. The compiler does not realize that [1, 2, 3]
> >means a static array in this context. You have to write
> >bar(cast(int[3]) [1, 2, 3]); but I think the compiler have to
> >recognize this on it's own.
>
> This is true. The problem is, as you say, that the compiler treats
> array literals as dynamic rather than static arrays. I would argue
> this is the correct default, but it's obviously not the default you
> want here.
>
> bearophile has posted about this on numerous occasions, and it's among
> his top thousand wanted features. :p
[...]
I have to chime in here and say that I'm not particularly happy with the
way dmd currently processes array literals. I think dmd currently
doesn't take type inference far enough. If a particular array literal is
being passed to a function that expects a static array, say, then it
should be able to interpret the literal as a static array of the
matching type.
Similarly, when you have, say, a template function:
func(T)(T[] args) if (is(T==short)) { ... }
Supposing there is no other overload that accepts an integral array, the
compiler should know that when you write func([1,2,3]) the array literal
should be a short[]. Currently, it treats [1,2,3] as int[], and so fails
to match the template. Lots of ugly hacks and workarounds are necessary
to make things work correctly.
I say this is one area where things need improvement. Especially since
type inference is one of D's major selling points (what with voldemort
types, etc., that doesn't require the user to spell out a long
complicated name just to use a range function in std.range, among many
other nice perks).
T
--
Never ascribe to malice that which is adequately explained by incompetence. --
Napoleon Bonaparte
