Re: 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. :)