<div dir="ltr"><div dir="ltr">On Mon, Nov 2, 2020 at 8:15 AM Ola Fosheim Grøstad via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sunday, 1 November 2020 at 21:47:26 UTC, Manu wrote:<br>
> Why? I don't agree with this at all. I actually expect tuples <br>
> DON'T have struct semantics.<br>
<br>
Well, it is a good thing if they behave as immutable structs as <br>
you then can get a more uniform language.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> The thing my DIP talks about are things that don't have struct <br>
> semantics...<br>
> what is that called?<br>
<br>
I was wrong, in a way, as structs can have aliases as fields (I <br>
believe phobos Tuple does this?). Although it would be better if <br>
it was more akin to typeid so that they had a counterpart at <br>
runtime (so that a regular function can return all tuples), but <br>
that would require a language change.<br>
<br>
But it would also make what Stephan try to do easier? His <br>
typefunctions would just be regular functions returning a <br>
type-identifer.<br></blockquote><div><br></div><div>I think type functions are a great initiative, and I've talked with him about that a lot.</div><div>I don't think this DIP competes with type functions. I also think type functions will need a LOT of work to materialise.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Make a DIP then. I don't like that idea. It's problematic to <br>
> know if you are dealing with a kind of thing that can be <br>
> unrolled until much later in semantic when it should have <br>
> already been done.<br>
<br>
The semantic passes can determine when the operator should be <br>
evaluated.<br></blockquote><div><br></div><div>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.<br></div><div>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.<br></div><div><br></div><div>Imagine this:</div><div>  void fun(MyRange r) { ... }<br></div><div><br></div><div>  MyRange constantRange;</div><div>  fun(constantRange); // <-- function receives range as argument<br></div><div>  fun(expr(constantRange)...); // <-- the function call fails because the range got turned into a tuple.</div><div><br></div><div><br></div><div>Or this:<br></div><div>  immutable int[] allTheThings = [ ... ];</div><div>  alias Selection = AliasSeq!(5, 1, 15);</div><div>  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<br></div><div><br></div><div>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.</div><div>This DIP applies to tuples, specifically, and exclusively. You need to design a completely different DIP if you think that's wrong.<br></div></div></div>