I dun a DIP, possibly the best DIP ever

[Manu]

On Fri, Apr 24, 2020 at 12:20 AM WebFreak001 via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Thursday, 23 April 2020 at 14:06:03 UTC, Stefan Koch wrote:
> > On Thursday, 23 April 2020 at 13:48:54 UTC, Steven
> > Schveighoffer wrote:
> >>
> >> No, Foo!(AliasSeq!(1, 2)...)... is equivalent to
> >> Foo!(AliasSeq!(1, 2))
> >>
> > In the current implementation it's a parser error.
>
> I would assume that both
>
> alias Numbers = AliasSeq!(1, 2);
> Foo!(Numbers...)
>
> and
>
> Foo!(AliasSeq!(1, 2)...)
>
> should do the same, no?
>

Well, they both do nothing.
You probably mean

Foo!(Numbers)...
Foo!(AliasSeq!(1, 2))...

But even then, no; there's no tuple to expand in that second statement.
What there is, is a template instantiation, and it _resolves_ to a tuple,
but the current spec doesn't tunnel into post-evaluation tuples like that.
If it did, I think it would be very unwieldy.
Expansion occurs before expression evaluation... and it must, because the
expression to evaluate is the result of the expansion.

I think of something like (expr + Tuple)... as a simple map!(Item
> => expr + Item) - however the compiler automatically finding the
> Tuple and the scope of the expression really bugs me the most
> here because it feels so subjective.
>
> Wouldn't some syntax like Tuple->{Tuple + 4} be clearer and
> easier to parse for both DMD and static analysis tools? To keep
> it as simple as possible it would just reuse the name of the
> tuple as item name, but then it's basically a fancy, clear map
> syntax, where you exactly control the tuple that's being expanded
> and avoid any issues with nested tuples in the expression tree.
>

What you're describing is something that starts to look like type
functions, or a type lambda specifically.
I'm all for type functions, but that's not what this DIP is. I'm in full
support of a type functions DIP though!

> clearer and easier to parse for both DMD

This has been surprisingly easy to implement. It's trivial to parse, and
semantic has been totally self-contained. The complexity we've discovered
is pretty much 100% concerning the moment that expansion is applied vs
semantic being run. Expansion must apply before the expression evaluation,
because the expansion affects the expression to be evaluated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200424/f14d7488/attachment.htm>