<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 3, 2020 at 8:55 AM Q. Schroll via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wednesday, 28 October 2020 at 10:57:37 UTC, Jacob Carlborg <br>
wrote:<br>
> On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:<br>
>> This is the discussion thread for the first round of Community <br>
>> Review of DIP 1037, "Add Unary Operator ...":<br>
>><br>
>> <a href="https://github.com/dlang/DIPs/blob/ba81eec84ddf0aeeb2cb652743b292455ec8c62a/DIPs/DIP1037.md" rel="noreferrer" target="_blank">https://github.com/dlang/DIPs/blob/ba81eec84ddf0aeeb2cb652743b292455ec8c62a/DIPs/DIP1037.md</a><br>
><br>
> Is there a risk of causing some form of ambiguity with variadic <br>
> functions?<br>
<br>
No, because the DIP does not propose anything with types. In the <br>
DIP, it says "expression" everywhere; it's for use in <br>
expressions, not types. It doesn't forbid types to occur in the <br>
tuple for good reasons, simply because types can very well occur <br>
in expression contexts, but the result will always be an <br>
expression. If you want a drastic example how far reaching <br>
expression vs type context is: given a type T, T[] can mean: <br>
slice of T or T.opIndex. If T defines static opIndex, in an <br>
expression context, T[] will mean T.opIndex, and in a type <br>
context, it will mean slice of T (kinda obvious). Let Ts := (T1, <br>
T2); if you'd do (Ts[]).sizeof... --- because ... is only valid <br>
in an expression context --- it *must* lower to <br>
(T1.opIndex.sizeof, T2.opIndex.sizeof). By the grammar given in <br>
the DIP, the ... do not have anything to do with the type <br>
expression stuff.<br>
<br>
The example given in the DIP with `cast(Types)Values...` might <br>
work by accident because types are also expressions. By the <br>
grammar provided, `cast(Types[])Values...` could never work as <br>
intended! The example<br>
<br>
alias staticMap(alias F, T...) = F!T...;<br>
<br>
cannot work. By the grammar provided, F!T... must be an <br>
expression, not a "type expression", but alias requires a type <br>
context as its target. (I.e. alias x = 5; doesn't work; alias x = <br>
y + 1; doesn't work either because the right-hand sides aren't <br>
types.)<br>
<br>
In the Feedback Thread, I commented that it would be great to <br>
have the proposed operator apply to type contexts as well [1]. <br>
Didn't get an answer, but do hope I get one eventually.<br>
<br>
Problem is, as you started digging: For a class C (and classes <br>
only, not structs or anything else), the parameter definition <br>
C... is already defined [2, see "4. For class objects"]. For <br>
example,<br>
<br>
class C { this(int, string) { } }<br>
void foo(C...) { }<br>
void main() { foo(1, "abc"); }<br>
<br>
compiles [3]. So if C is the last entry in a type-only AliasSeq <br>
that is used in a parameter list, notations clash. Currently <br>
valid [4] code like<br>
<br>
import std.meta : AliasSeq;<br>
class C { this(int, string) { } }<br>
alias Types = AliasSeq!(int, string, C);<br>
void foo(Types args...) { }<br>
void main() { foo(1, "abc", 2, "xyz"); }<br>
<br>
would no longer compile, since `Types...` would be the literal <br>
same as using `Types` without dots.<br>
<br>
[1] <br>
<a href="https://forum.dlang.org/post/fogbdhcdeukiucbxxxns@forum.dlang.org" rel="noreferrer" target="_blank">https://forum.dlang.org/post/fogbdhcdeukiucbxxxns@forum.dlang.org</a><br>
[2] <br>
<a href="https://dlang.org/spec/function.html#typesafe_variadic_functions" rel="noreferrer" target="_blank">https://dlang.org/spec/function.html#typesafe_variadic_functions</a><br>
[3] <a href="https://run.dlang.io/is/GmgAaG" rel="noreferrer" target="_blank">https://run.dlang.io/is/GmgAaG</a><br>
[4] <a href="https://run.dlang.io/is/DeGZF7" rel="noreferrer" target="_blank">https://run.dlang.io/is/DeGZF7</a></blockquote><div><br></div><div>Thank you for this analysis. This is useful. I'll confirm the DIP's spec and implementation against your points.</div><div>It might be that the implementation works by happen-stance, or perhaps my stated grammar change wasn't accurate.</div><div>It's very hard to express a grammar change in a DIP like this, since D doesn't have a grammar as such; it's just an implementation, and reverse-engineering a grammar from the implementation is imprecise. Perhaps my implementation implies additional grammar changes that I didn't notice.</div></div></div>