On Sunday, 1 November 2020 at 21:47:26 UTC, Manu wrote:
> Why? I don't agree with this at all. I actually expect tuples
> DON'T have struct semantics.
Well, it is a good thing if they behave as immutable structs as
you then can get a more uniform language.
I think it is conceptually improper for a tuple to have a memory layout; especially considering tuples can hold elements that are types or aliases in addition to typed values.
> The thing my DIP talks about are things that don't have struct
> semantics...
> what is that called?
I was wrong, in a way, as structs can have aliases as fields (I
believe phobos Tuple does this?). Although it would be better if
it was more akin to typeid so that they had a counterpart at
runtime (so that a regular function can return all tuples), but
that would require a language change.
But it would also make what Stephan try to do easier? His
typefunctions would just be regular functions returning a
type-identifer.
I think type functions are a great initiative, and I've talked with him about that a lot.
I don't think this DIP competes with type functions. I also think type functions will need a LOT of work to materialise.
> Make a DIP then. I don't like that idea. It's problematic to
> know if you are dealing with a kind of thing that can be
> unrolled until much later in semantic when it should have
> already been done.
The semantic passes can determine when the operator should be
evaluated.
Under my DIP, the map is applied very early, pre-semantic. The resulting tuple must compile in context and make semantic sense, and this is very important such that it can be used in a wide variety of interesting contexts.
It's also extremely complicated to know what the output of `...` applied to an array-like thing should be? Is it a tuple? If you apply `...` to an array or a range, and it becomes a tuple, that is probably going to reveal serious semantic problems.
Imagine this:
void fun(MyRange r) { ... }
MyRange constantRange;
fun(constantRange); // <-- function receives range as argument
fun(expr(constantRange)...); // <-- the function call fails because the range got turned into a tuple.
Or this:
immutable int[] allTheThings = [ ... ];
alias Selection = AliasSeq!(5, 1, 15);
alias res = allTheThings[Selection]...; // <-- we have an array, and a tuple both participating in the map; if `...` applied to array-like-things, then this extremely important pattern would be impossible
If it attempts a parallel expansion as is specified in the DIP, then immediately, the lengths do not match, but more importantly, the expression doesn't even make functional sense anymore.
This DIP applies to tuples, specifically, and exclusively. You need to design a completely different DIP if you think that's wrong.