Type inference and overloaded functions

[Namespace]

On Tuesday, 10 December 2013 at 09:42:50 UTC, Jonathan M Davis 
wrote:
> On Tuesday, December 10, 2013 10:33:33 Namespace wrote:
>> On Tuesday, 10 December 2013 at 09:28:27 UTC, Jonathan M Davis
>> 
>> wrote:
>> > On Tuesday, December 10, 2013 10:10:22 Namespace wrote:
>> >> Yeah I remember, but Kenji made a Pull Request to change 
>> >> this.
>> >> Regardless it would be very useful to have static array
>> >> literals.
>> > 
>> > It should be possible to do that via a templated function 
>> > which
>> > takes a static
>> > array and then returns it. e.g.
>> > 
>> > auto staticLiteral(T, size_t n)(T[n] literal)
>> > {
>> > 
>> >     return literal;
>> > 
>> > }
>> > 
>> > auto staticArray = staticLiteral([1, 2, 3, 4]);
>> > 
>> > The compiler should optimize out the heap allocation, since 
>> > the
>> > literal is
>> > directly converted to a static array (it might not optimize 
>> > it
>> > now, but it
>> > definitely should, in which case, you're effectively 
>> > creating a
>> > static array
>> > literal without any heap allocations).
>> > 
>> > Maybe that's more verbose than would be ideal, but it allows 
>> > us
>> > to essentially
>> > have static array literals without having to add anything to
>> > the language.
>> > 
>> > - Jonathan M Davis
>> 
>> Ugly. Why not {1, 2, 3} or [1, 2, 3]s. The compiler could (as
>> long as necessary) rewrite this to your ugly solution.
>> But library solutions are always ugly and mostly bad and bug
>> prone. See scoped, Typedef and destroy.
>
> Walter and Andrei are very much against adding anything further 
> to the
> language when it can be done in a library instead. {1, 2, 3} 
> conflicts with C-
> style struct construction, and while [1, 2, 3]s is nice and 
> short, all it does
> over staticLiteral([1, 2, 3]) is save some typing, and it 
> requires language
> changes, whereas it's trivial in comparison to do something 
> like this in a
> library. In fact, if we were to start over with D now, there 
> would be a number
> of things that would just be in the library instead of the 
> language (e.g.
> Andrei has stated several times that new should not have been a 
> keyword and
> that it should have been handled by the standard library 
> instead of the
> language). But it's too late for that now, so pretty much all 
> of the stuff that
> might not end up the language if we were to start over is going 
> to stay.
> However, that doesn't mean that we're going to be anything more 
> like that in
> the language when we can do it in the library.
>
> - Jonathan M Davis
scoped waste a lot of space, Typedef is mostly unuseable and 
destroy is buggy with alias this and doesn't free the space (of 
course this is intended). I would prefer to do nothing, than a 
library solution. But let's wait and see. :)