I dun a DIP, possibly the best DIP ever

[WebFreak001]

On Wednesday, 22 April 2020 at 13:45:52 UTC, WebFreak001 wrote:
> On Wednesday, 22 April 2020 at 12:19:25 UTC, rikki cattermole 
> wrote:
>> Change it to something like .unpackSequence instead of ... and 
>> I would be happy.
>
> I'm for some other thing than ... too, in C++ it's a quite bad 
> syntax and it can become very ugly to maintain with all the 
> different combinations you could use it with from a compiler 
> viewpoint. Additionally if you do miss some combinations or 
> allow more complex operators it will quickly become a mess of 
> "why does this compile but why doesn't this compile" or "why 
> does this do something different"
>
> I'm especially not a fan of allowing all of
> (Tup*10)...  -->  ( Tup[0]*10, Tup[1]*10, ... , Tup[$-1]*10 )
> and
> (Tup1*Tup2)...
> and
> myArr[Tup + 1]... -> myArr[Tup[0] + 1], myArr[Tup[1] + 1], 
> myArr[Tup[2] + 1]
>
> would this be valid:
> f!T...(x)
> or rather this?
> f!T(x)...
>
> what does (cast(Tup)x)... evaluate to?
>
> is f(Tup) and f(Tup...) now doing the same thing?
>
> if
> f(Items.x...)
> works then what about
> f(Items.MemberTup...) ?

Because it is basically just staticMap but with syntax from the 
compiler, how about something like

Tup->{Tup*4}

where each item in the tuple gets replaces with what is inside 
the {} ; Might want to instead have some item variable name and 
maybe even index counter but I can't think of some good syntax 
here or of any use cases right now.

This might be too powerful though because it's basically AST 
macros now if you allow this:

StringTup->{StringTup ~ } ":)"    <- like "a" ~ "b" ~ ":)"

or

Tup->{cast(Tup)}c    <- like cast(int)cast(short)c

But if you implemented this syntax in the compiler you would 
manually specify all the allowed rules inside the {} block, so it 
would definitely be harder to introduce weird allowed/disallowed 
syntax rules.