Type inference and overloaded functions

Jonathan M Davis jmdavisProg at gmx.com
Tue Dec 10 01:42:33 PST 2013


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


More information about the Digitalmars-d-learn mailing list