www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1023--Resolution of Template Alias Formal Parameters in Template

reply Mike Parker <aldacron gmail.com> writes:
This is the feedback thread for the first round of Community 
Review for DIP 1023, "Resolution of Template Alias Formal 
Parameters in Template Functions":

https://github.com/dlang/DIPs/blob/bf5157d3dc29a591826e22d188448fbc04ca81b2/DIPs/DIP1023.md

All review-related feedback on and discussion of the DIP should 
occur in this thread. The review period will end at 11:59 PM ET 
on September 20, or when I make a post declaring it complete.

At the end of Round 1, if further review is deemed necessary, the 
DIP will be scheduled for another round of Community Review. 
Otherwise, it will be queued for the Final Review and Formal 
Assessment.

Anyone intending to post feedback in this thread is expected to 
be familiar with the reviewer guidelines:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

Thanks in advance for keeping all discussion on topic.
Sep 06
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
The D code blocks should have the language set to D (```d ... ```) for 
easier reading.



Your examples in abstract didn't look right.
I ran the second to confirm my suspicion:

onlineapp.d(9): Error: undefined identifier T



Here is the test case in your implementation linked that made me 
understand your intention for the DIP:

```
void main() {
     TestAlias!(int, float) testObj;
     testFunction(testObj);
}

struct TestType(T, Q) { }
alias TestAlias(T, Q) = TestType!(T, Q);
static void testFunction(T, Q)(TestAlias!(T, Q) arg) { }
```

Current error:

onlineapp.d(5): Error: template onlineapp.testFunction cannot deduce 
function from argument types !()(TestType!(int, float)), candidates are:
onlineapp.d(10):        onlineapp.testFunction(T, Q)(TestAlias!(T, Q) arg)
Sep 06
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Friday, 6 September 2019 at 12:17:11 UTC, rikki cattermole 
wrote:
 The D code blocks should have the language set to D (```d ... 
 ```) for easier reading.
Thanks, I didn't know about that.
 Your examples in abstract didn't look right.
 I ran the second to confirm my suspicion:

 onlineapp.d(9): Error: undefined identifier T
Could you paste the example that gave you this error? Btw, not all examples are compilable.
 Here is the test case in your implementation linked that made 
 me understand your intention for the DIP:

 ```
 void main() {
     TestAlias!(int, float) testObj;
     testFunction(testObj);
 }

 struct TestType(T, Q) { }
 alias TestAlias(T, Q) = TestType!(T, Q);
 static void testFunction(T, Q)(TestAlias!(T, Q) arg) { }
 ```

 Current error:

 onlineapp.d(5): Error: template onlineapp.testFunction cannot 
 deduce function from argument types !()(TestType!(int, float)), 
 candidates are:
 onlineapp.d(10):        onlineapp.testFunction(T, 
 Q)(TestAlias!(T, Q) arg)
Yes, this example shows exactly the intention. Among other things, the DIP proposes that we should not have an error here.
Sep 06
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 6 September 2019 at 12:27:50 UTC, Stefanos Baziotis 
wrote:


 Thanks, I didn't know about that.
My bad. I should have caught that when I was revising. I don't normally like to push changes to a DIP under review, but anyone who would prefer to see the DIP with proper highlights is located here: https://github.com/dlang/DIPs/blob/840083a91f4c110832c1d0b61008935b277e32db/DIPs/DIP1023.md
Sep 06
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 07/09/2019 12:27 AM, Stefanos Baziotis wrote:
 On Friday, 6 September 2019 at 12:17:11 UTC, rikki cattermole wrote:
 The D code blocks should have the language set to D (```d ... ```) for 
 easier reading.
Thanks, I didn't know about that.
 Your examples in abstract didn't look right.
 I ran the second to confirm my suspicion:

 onlineapp.d(9): Error: undefined identifier T
Could you paste the example that gave you this error? Btw, not all examples are compilable.
This one should be since it is stating current behavior. Looks like I got it wrong, its third not second: ``` struct TemplateType(T) { } alias TemplateAlias(T) = TemplateType!T void templateFunction(TemplateAlias!T arg) { } ``` Two errors (missed the first, semicolon missing). So: ``` struct TemplateType(T) { } alias TemplateAlias(T) = TemplateType!T; void templateFunction(T)(TemplateAlias!T arg) { } ```
 Here is the test case in your implementation linked that made me 
 understand your intention for the DIP:

 ```
 void main() {
     TestAlias!(int, float) testObj;
     testFunction(testObj);
 }

 struct TestType(T, Q) { }
 alias TestAlias(T, Q) = TestType!(T, Q);
 static void testFunction(T, Q)(TestAlias!(T, Q) arg) { }
 ```

 Current error:

 onlineapp.d(5): Error: template onlineapp.testFunction cannot deduce 
 function from argument types !()(TestType!(int, float)), candidates are:
 onlineapp.d(10):        onlineapp.testFunction(T, Q)(TestAlias!(T, Q) 
 arg)
Yes, this example shows exactly the intention. Among other things, the DIP proposes that we should not have an error here.
I replied with this so that you had feedback for improving the DIP if other people find it hard to understand.
Sep 06
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
Thanks Mike and jmh530.

On Friday, 6 September 2019 at 12:48:34 UTC, rikki cattermole 
wrote:
 This one should be since it is stating current behavior.

 Looks like I got it wrong, its third not second:

 ```
 struct TemplateType(T) { }
 alias TemplateAlias(T) = TemplateType!T
 void templateFunction(TemplateAlias!T arg) { }
 ```

 Two errors (missed the first, semicolon missing).
 So:

 ```
 struct TemplateType(T) { }
 alias TemplateAlias(T) = TemplateType!T;
 void templateFunction(T)(TemplateAlias!T arg) { }
 ```
Indeed. Thanks, it will be corrected. Do I wait for the next round to do corrections?
 I replied with this so that you had feedback for improving the 
 DIP if other people find it hard to understand.
You mean include this in the DIP? In the "Description" section there's an identical example.
Sep 06
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 07/09/2019 12:58 AM, Stefanos Baziotis wrote:
 Thanks Mike and jmh530.
 
 On Friday, 6 September 2019 at 12:48:34 UTC, rikki cattermole wrote:
 This one should be since it is stating current behavior.

 Looks like I got it wrong, its third not second:

 ```
 struct TemplateType(T) { }
 alias TemplateAlias(T) = TemplateType!T
 void templateFunction(TemplateAlias!T arg) { }
 ```

 Two errors (missed the first, semicolon missing).
 So:

 ```
 struct TemplateType(T) { }
 alias TemplateAlias(T) = TemplateType!T;
 void templateFunction(T)(TemplateAlias!T arg) { }
 ```
Indeed. Thanks, it will be corrected. Do I wait for the next round to do corrections?
Unless Mike says otherwise, yes.
 I replied with this so that you had feedback for improving the DIP if 
 other people find it hard to understand.
You mean include this in the DIP? In the "Description" section there's an identical example.
No. It is for future reference if there is a trend of people finding it hard to follow.
Sep 06
parent Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Friday, 6 September 2019 at 13:10:49 UTC, rikki cattermole 
wrote:
 You mean include this in the DIP? In the "Description" section 
 there's an
 identical example.
No. It is for future reference if there is a trend of people finding it hard to follow.
Ah yes of course, thanks for referencing it.
Sep 06
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 6 September 2019 at 12:58:33 UTC, Stefanos Baziotis 
wrote:
 Thanks Mike and jmh530.

 [snip]
I'm sure I could find some way to simplify this what's below, but I've just been thinking about Atila's concepts library and it's interaction with this DIP [1]. Removing the concepts-specific part of it, it becomes void checkFoo(T)() { T t = T.init; t.foo(); } enum isFoo(T) = is(typeof(checkFoo!T)); struct Foo { void foo() {} } I'm curious if this DIP is accepted could something like the following work template Foo_able(T) if (isFoo!T) { alias Foo_able = T; } void useFoo(T)(auto ref Foo_able!T x) { } void main() { Foo x; useFoo(x); } Right now, to get it to work would require writing useFoo!Foo(x) because the Foo is not detected to be a Foo_able!T. If something like the above works under this DIP, while I grant I don't think that this resolves all of the issues that the concepts library tries to address, I think it would be a win for readability. The big thing that the concepts library provides over what is above is improved error messages (as of now, it is just a replacement of the template constraint). It tells you why the argument does not fit. It seems like if the alias is transformed to something like below, still using the concepts library, then it you would still be able to get the improved error messages. You wouldn't need to apply the models UDA to the struct in this case in order to get the good error messages. template Foo_able(T) { static assert(models!(T, isFoo)); alias Foo_able = T; } [1] https://github.com/atilaneves/concepts
Sep 10
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Tuesday, 10 September 2019 at 14:06:10 UTC, jmh530 wrote:
 On Friday, 6 September 2019 at 12:58:33 UTC, Stefanos Baziotis 
 wrote:
 Thanks Mike and jmh530.

 [snip]
I'm sure I could find some way to simplify this what's below, but I've just been thinking about Atila's concepts library and it's interaction with this DIP [1]. Removing the concepts-specific part of it, it becomes void checkFoo(T)() { T t = T.init; t.foo(); } enum isFoo(T) = is(typeof(checkFoo!T)); struct Foo { void foo() {} } I'm curious if this DIP is accepted could something like the following work template Foo_able(T) if (isFoo!T) { alias Foo_able = T; } void useFoo(T)(auto ref Foo_able!T x) { } void main() { Foo x; useFoo(x); } Right now, to get it to work would require writing useFoo!Foo(x) because the Foo is not detected to be a Foo_able!T. If something like the above works under this DIP, while I grant I don't think that this resolves all of the issues that the concepts library tries to address, I think it would be a win for readability.
TBH, I did not understand completely the code. From what I can tell, this DIP doesn't have connection with the code above because there's no alias. But this might be an oversimplification and I might have missed something.
 The big thing that the concepts library provides over what is 
 above is improved error messages (as of now, it is just a 
 replacement of the template constraint). It tells you why the 
 argument does not fit. It seems like if the alias is 
 transformed to something like below, still using the concepts 
 library, then it you would still be able to get the improved 
 error messages. You wouldn't need to apply the models UDA to 
 the struct in this case in order to get the good error messages.

 template Foo_able(T)
 {
     static assert(models!(T, isFoo));
     alias Foo_able = T;
 }
Again, sorry for not understanding. I'm not familiar with the concepts library. From what I can tell, this again has no connection with the DIP. The alias is not a template alias and it's not used as a function argument. - Stefanos
Sep 10
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 10 September 2019 at 21:48:33 UTC, Stefanos Baziotis 
wrote:
 [snip]

 TBH, I did not understand completely the code. From what I can 
 tell,
 this DIP doesn't have connection with the code above because
 there's no alias. But this might be an oversimplification and
 I might have missed something.
What do you mean there is no alias? This is an alias: template Foo_able(T) if (isFoo!T) { alias Foo_able = T; } It's using the explicit template syntax. The template documentation [1] has "template TFoo(T) { alias Ptr = T*; }" as an example. This is very similar except it has a template constraint and I use an eponymous template. Without the template constraint it is template Foo_able(T) { alias Foo_able = T; } For your other point, if above is a template alias, then the other must also (just adding in a static assert). Regardless, it would be used as a function parameter in the useFoo function. [1] https://dlang.org/spec/template.html
Sep 10
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 10 September 2019 at 21:48:33 UTC, Stefanos Baziotis 
wrote:
 [snip]
Here is a simpler example: import std.traits : isNumeric; template Foo(T) if (isNumeric!T) { alias Foo = T; } void useFoo(T)(Foo!T x) { } void main() { int x; useFoo!int(x); useFoo(x); //error currently, will it compile with this DIP? }
Sep 10
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Wednesday, 11 September 2019 at 00:35:26 UTC, jmh530 wrote:
 On Tuesday, 10 September 2019 at 21:48:33 UTC, Stefanos 
 Baziotis wrote:
 [snip]
Here is a simpler example: import std.traits : isNumeric; template Foo(T) if (isNumeric!T) { alias Foo = T; } void useFoo(T)(Foo!T x) { } void main() { int x; useFoo!int(x); useFoo(x); //error currently, will it compile with this DIP? }
Thanks, that is clearer. And I understand the reasoning now. Yes, it should. As far as I can tell, the draft PR had a more complicated test case / example than this. You can check it here [1] [1] https://github.com/dlang/dmd/pull/9778/files#diff-f1fd9ecb820a6d8a95c2ba9675ce5071R34
Sep 10
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Wednesday, 11 September 2019 at 01:39:22 UTC, Stefanos 
Baziotis wrote:
 Yes, it should. As far as I can tell, the draft
 PR had a more complicated test case / example than this.
Actually, just checked on the draft PR, it doesn't work. First of all, sorry for the fact that I have forgotten a lot of things regarding the implementation and the DIP. This implementation and DIP were authored 4 months ago. As I understand it, because this PR and DIP handle template alias, they don't handle templates (that may somehow resolve to aliases). That may be an omission or it may be out of scope of this DIP. Let me try to make this more clear. The first test case in the PR is: struct TestType(T, Q) { } alias TestAlias(T, Q) = TestType!(T, Q); static void testFunction(T, Q)(TestAlias!(T, Q) arg) { } void main() { TestAlias!(int, float) testObj; // This resolves to TestType testFunction(testObj); // testObj is passed with type TestType } So, right now, the _actual_ argument has the resolved type but the _formal_ argument (i.e. `arg`) has not. It has TestAlias. And so, we try to replace this formal argument type with the actual type. One could say that your example looks similar. We want to resolve the formal argument `x` to its actual type, but we're stuck in the Foo!T. The problem is that `Foo` is not an alias. It's a template. And with a contract in it. To me, it _seems_ like a similar logic, but the implementation and the semantic details (which also implies - the formal specification in the DIP) are quite different and would require major additions. We may need a separate DIP for this. Nonetheless, thank you very much for pointing it out! Either it's part of this DIP or not. - Stefanos
Sep 10
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 11.09.19 04:02, Stefanos Baziotis wrote:
 As I understand it, because this PR and DIP handle template alias, they 
 don't handle templates (that may somehow resolve to aliases).
A "template alias" is nothing but a (simple) template that resolves to an alias. This: alias Foo(T) = ...; is just short for this: template Foo(T) { alias Foo = T; } They are exactly the same thing to the compiler. You can say that the DIP only applies to the simplest templates, i.e. no constraints, no specializations, no conditionals in the template, etc. But distinguishing between "template alias" and "template that resolves to an alias" makes no sense. By the way, the proper term is "alias template". https://dlang.org/spec/template.html#alias-template
Sep 10
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Wednesday, 11 September 2019 at 05:32:22 UTC, ag0aep6g wrote:
 A "template alias" is nothing but a (simple) template that 
 resolves to an alias.

 This:
     alias Foo(T) = ...;
 is just short for this:
     template Foo(T) { alias Foo = T; }
 They are exactly the same thing to the compiler.
We should be more precise here. 2 things that are semantically the same might not be the same for the compiler (and the compiler's job is to handle them as the same). A trivial example is this: ``` alias my_int = int; my_int x; ... ``` my_int and int are semantically exactly the same, but to the compiler they're not. The compiler has to do work to handle them as the same. I'm not saying that in your example they are or not, because I don't know / remember. You might do though. But this is an important distinction. As far as I remember, they're not handled as the same and I wouldn't think that they're handled the same as well. As another point, and this is the only important thing to a DIP (aka formal specification): 2 things might be semantically the same but not formally the same. The example above is in that category. The one is an alias declaration and the other a built-in type. But the specification should say that they should be handled the same. As far as I'm concerned, your example is a template declaration that resolves to an alias declaration, which is different from an alias declaration. - Stefanos
Sep 11
parent reply ag0aep6g <anonymous example.com> writes:
On 11.09.19 13:49, Stefanos Baziotis wrote:
 On Wednesday, 11 September 2019 at 05:32:22 UTC, ag0aep6g wrote:
 A "template alias" is nothing but a (simple) template that resolves to 
 an alias.

 This:
     alias Foo(T) = ...;
 is just short for this:
     template Foo(T) { alias Foo = T; }
 They are exactly the same thing to the compiler.
We should be more precise here. 2 things that are semantically the same might not be the same for the compiler (and the compiler's job is to handle them as the same).
Ok, sure. The difference is in syntax. It's the compiler's job to interpret the shorthand variant exactly like the longhand.
 A trivial example is this:
 ```
 alias my_int = int;
 
 my_int x;
 ...
 ```
 
 my_int and int are semantically exactly the same, but to the compiler 
 they're
 not. The compiler has to do work to handle them as the same.
And it might make sense to focus on that difference if you're writing a DIP that changes the meaning of `alias`. But if you're writing a DIP that changes the meaning of `int`, then we expect that is also applies to `my_int`. So unless your DIP states that it changes the meaning of the alias template shorthand syntax, we expect that it also works with the longhand.
 I'm not saying that in your example they are or not, because I don't 
 know / remember. You might do though.
 But this is an important distinction. As far as I remember, they're
 not handled as the same and I wouldn't think that they're handled the same
 as well.
As far as I understand, you suspect a semantic difference. If that's so, you're simply mistaken.
 As another point, and this is the only important thing to a DIP (aka formal
 specification): 2 things might be semantically the same but not formally
 the same. The example above is in that category. The one is an alias 
 declaration
 and the other a built-in type. But the specification should say that they
 should be handled the same.
I'm not sure what "formally the same" would entail. Syntactically, the two variants are different (obviously). But that's it. Semantically, the shorthand is defined to mean whatever the longhand means [1].
 As far as I'm concerned, your example is a template declaration that 
 resolves
 to an alias declaration, which is different from an alias declaration.
Syntactically, `template Foo(T) { alias Foo = T; }` is called a "TemplateDeclaration". Semantically, it declares a template. Syntactically, `alias Foo(T) = T;` is called an "AliasDeclaration". Semantically, it also declares a template. It doesn't declare an alias. [1] https://dlang.org/spec/template.html#alias-template
Sep 11
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Wednesday, 11 September 2019 at 14:14:31 UTC, ag0aep6g wrote:
 And it might make sense to focus on that difference if you're 
 writing a DIP that changes the meaning of `alias`. But if 
 you're writing a DIP that changes the meaning of `int`, then we 
 expect that is also applies to `my_int`.
It doesn't change the meaning of alias. It changes how an alias declaration / instantiation acts.
 So unless your DIP states that it changes the meaning of the 
 alias template shorthand syntax, we expect that it also works 
 with the longhand.
It does as far as I'm concerned. It always states alias declarations [1] and template alias instantiations with regard to alias declarations. The "longhand" version is not an alias declaration, it is a template declaration.
 As far as I understand, you suspect a semantic difference. If 
 that's so, you're simply mistaken.
Firstly, there are things to consider regarding the handling inside the compiler. Although that has to do with the implementation, which I don't think we should focus on. The thing is, semantics is about what something means. But, regarding formal specifications, there's another important topic. Actually, the most important for this DIP, which is how something is resolved to be a specific semantic entity. The "longhand" and "shorthand" versions are semantically the same, i.e. they correspond to the same semantic entity, but the way one arrives to this entity is different. Meaning, the rules applied. And one should consider that. Otherwise, the burden is left to the compiler implementor.
 I'm not sure what "formally the same" would entail. 
 Syntactically, the two variants are different (obviously). But 
 that's it. Semantically, the shorthand is defined to mean 
 whatever the longhand means [1].
As I said above, in the way I understand it, one thing representing the same with another is not enough. If that was so, this DIP would not even be needed since most of its work is to describe the resolution procedure.
 Syntactically, `template Foo(T) { alias Foo = T; }` is called a 
 "TemplateDeclaration". Semantically, it declares a template.

 Syntactically, `alias Foo(T) = T;` is called an 
 "AliasDeclaration". Semantically, it also declares a template. 
 It doesn't declare an alias.
Yes, but they're different. Again, going to what I said above.
Sep 11
parent reply ag0aep6g <anonymous example.com> writes:
On 11.09.19 17:48, Stefanos Baziotis wrote:
 On Wednesday, 11 September 2019 at 14:14:31 UTC, ag0aep6g wrote:
[...]
 So unless your DIP states that it changes the meaning of the alias 
 template shorthand syntax, we expect that it also works with the 
 longhand.
It does as far as I'm concerned. It always states alias declarations [1] and template alias instantiations with regard to alias declarations. The "longhand" version is not an alias declaration, it is a template declaration.
So you intend to introduce a difference between shorthand and longhand alias templates? That's awful. To me, that would be a reason to reject the DIP. [...]
 Firstly, there are things to consider regarding the handling
 inside the compiler. Although that has to do with
 the implementation, which I don't think we should focus on.
 
 The thing is, semantics is about what something means.
 But, regarding formal specifications, there's another
 important topic. Actually, the most important for this DIP,
 which is how something is resolved to be a specific semantic
 entity.
 The "longhand" and "shorthand" versions are semantically the same,
 i.e. they correspond to the same semantic entity, but the way
 one arrives to this entity is different. Meaning, the rules
 applied.
 And one should consider that. Otherwise, the burden
 is left to the compiler implementor.
If I understand correctly, you're saying that you want to consider ease of implementation in the compiler. That's fine. But: 1) It's not obvious that you're actually simplifying the implementation by restricting the feature to the shorthand syntax. Your prototype implementation seems to work just fine with the longhand syntax. 2) Even if it happens to be easier to implement, you have to weigh that against adding a surprising special case to the language. I don't think it's going to be a net positive.
Sep 11
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Wednesday, 11 September 2019 at 17:53:06 UTC, ag0aep6g wrote:
 So you intend to introduce a difference between shorthand and 
 longhand alias templates?
Not necessarily. But let's say I do (as it seems the DIP does currently) for the rest of this and I will discuss the alternative I'm thinking in the end.
 That's awful. To me, that would be a reason to reject the DIP.
Indeed. :/ When I wrote this DIP, I hadn't thought about the long-hand version. That may seem quite naive, but consider that I was quite new to D and the use cases I was presented then were using only the short-hand version. FWIW, this DIP and its use cases / needs were not mine. But I liked the idea and did the authoring.
 If I understand correctly, you're saying that you want to 
 consider ease of implementation in the compiler.
Not necessarily. That would be good but I'm more concerned about the complexity and clarity of the DIP.
 That's fine. But:

 1) It's not obvious that you're actually simplifying the 
 implementation by restricting the feature to the shorthand 
 syntax. Your prototype implementation seems to work just fine 
 with the longhand syntax.
Indeed it's not obvious.
 2) Even if it happens to be easier to implement, you have to 
 weigh that against adding a surprising special case to the 
 language. I don't think it's going to be a net positive.
Indeed. So, the alternative: My first thought is being more high level. That is, currently the DIP is restricted to alias declarations, while we can have the same exact semantic entity using a different type of declaration. This has a lot of subtle details. Can these declarations have a common way of resolution ? If yes, maybe this is too high-level and it results in yet another not-so-formal-but-intuitive description. If no, should we consider each case separately ? How many are they ? How complicated will the DIP be ? And it's not clear whether I will have the time to do this. Tell me what you think. - Stefanos
Sep 11
parent reply ag0aep6g <anonymous example.com> writes:
On 11.09.19 20:29, Stefanos Baziotis wrote:
 So, the alternative:
 My first thought is being more high level.
 That is, currently the DIP is restricted to alias declarations,
 while we can have the same exact semantic entity using a
 different type of declaration. This has a lot of subtle details.
 Can these declarations have a common way of resolution ?
The longhand is a common way. If you base your DIP on the longhand only, then the shorthand follows automatically, because it's defined to do whatever the longhand does. I.e., if your DIP says that this works: template A(T) { alias A = S!T; } /* longhand */ struct S(T) { } void f(T)(A!T arg) { } void main() { f(S!int()); } Then it follows from the existing spec that it also works when A is declared in shorthand style: alias A(T) = S!T; /* shorthand */ The shorthand is defined to be equivalent to the longhand, and the longhand works, so the shorthand also works. You don't even have to mention it in the DIP. It's already in the spec. By the way, the same shorthand/longhand thing applies to function templates. The DIP currently only uses the shorthand, but it should also work with the longhand (and I'd just assume that it does as long as the DIP doesn't explicitly say otherwise).
 If yes, maybe this is too high-level and it results in yet
 another not-so-formal-but-intuitive description.
 If no, should we consider each case separately ? How many are they ?
 How complicated will the DIP be ?
I feel like working on the (concrete) syntax level is too low-level. I think it's obvious that the new feature should be applied after lexing and parsing. You don't want to write your DIP in terms of characters or keywords. To me, it also seems obvious that the new feature should be applied after shorthand and longhand syntaxes have been consolidated. I'd expect that the parser already does this, but I'm not sure. Beyond that, I'm not knowledgeable enough to say when it should happen. If the shorthand/longhand consolidation is not done by the parser, and not in some very early semantics phase either, then that might make things complicated.
 And it's not clear whether I will have the time to do this.
That's perfectly understandable. No one (in their right mind) is going to blame you, if you don't manage to push this all the way. It's a hard problem. The oldest Bugzilla issue for it is over a decade old, with a dozen or so duplicates. Fixing/implementing that kind of issue isn't usually a walk in the park, or someone would already have done it.
Sep 11
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Wednesday, 11 September 2019 at 20:46:46 UTC, ag0aep6g wrote:
 The shorthand is defined to be equivalent to the longhand, and 
 the longhand works, so the shorthand also works. You don't even 
 have to mention it in the DIP. It's already in the spec.
I agree, changes have to be done though. Meaning, it should not focus on alias declaration, it should be more general.
 I feel like working on the (concrete) syntax level is too 
 low-level.

 I think it's obvious that the new feature should be applied 
 after lexing and parsing. You don't want to write your DIP in 
 terms of characters or keywords.

 To me, it also seems obvious that the new feature should be 
 applied after shorthand and longhand syntaxes have been 
 consolidated. I'd expect that the parser already does this, but 
 I'm not sure.

 Beyond that, I'm not knowledgeable enough to say when it should 
 happen. If the shorthand/longhand consolidation is not done by 
 the parser, and not in some very early semantics phase either, 
 then that might make things complicated.
It's not the syntactic part the problem, meaning parsing and lexing. It's the rewriting capabilities of templates. Check Description -> New (in bold) in the DIP. _However_, it's obvious that these rewriting problems don't apply only to alias declarations. Actually, they're borrowed from templates. AFAIK, these rewriting capabilities are not as formally described as they could, but it was not the initial intention of this DIP to describe and it won't be now. What I mean is that it seems feasible to describe the resolution pretty much the same way for both long-hand and short-hand.
 And it's not clear whether I will have the time to do this.
That's perfectly understandable. No one (in their right mind) is going to blame you, if you don't manage to push this all the way. It's a hard problem. The oldest Bugzilla issue for it is over a decade old, with a dozen or so duplicates. Fixing/implementing that kind of issue isn't usually a walk in the park, or someone would already have done it.
Indeed, although now it might be possible. When I was experimenting with this, the implementation seemed quite complicated indeed. So, I left it in a draft stage where I hope will be a good starting point or at least give an idea. (It actually solves the use cases that the people who wanted the feature are interested. That includes the cases in any issue report I had seen). Instead, I focused on describing the feature as completely as possible, which should help both the implementation and the consistency of the feature.
Sep 11
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 11 September 2019 at 22:30:31 UTC, Stefanos 
Baziotis wrote:
 [snip]
Another example of where something like what I had suggested above with constrained aliases might be useful. For whatever dumb reason, I was just playing around with restricting Algebraic to only allow numeric types. You have to create a new struct and add in some member functions to get it to work. You can do more-or-less the same thing with an alias, easier IMO, but then if a function calling that alias doesn't work as easily (for reasons discussed above in thread). import std.variant; import std.traits : isNumeric; import std.meta : allSatisfy; struct Foo(T...) if (allSatisfy!(isNumeric, T)) { Algebraic!(T) x; alias x this; this(U)(U val) { x = val; } void opAssign(U)(U val) { x = val; } } template Bar(T...) if (allSatisfy!(isNumeric, T)) { alias Bar = Algebraic!(T); } void useFoo(T...)(Foo!T x) { } void useBar(T...)(Bar!T x) { } void main() { import std.stdio : writeln; auto v = Foo!(int, double)(5); writeln(v.peek!(int)); writeln(v); v = 3.14; writeln(v.peek!(double)); writeln(v); auto w = Bar!(int, double)(5); useFoo(v); //useBar(w); //does not compile currently }
Sep 30
parent Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Monday, 30 September 2019 at 19:16:47 UTC, jmh530 wrote:
 On Wednesday, 11 September 2019 at 22:30:31 UTC, Stefanos 
 Baziotis wrote:
 [snip]
Another example of where something like what I had suggested above with constrained aliases might be useful.
Thanks for the info. It happened that just yesterday I updated the DIP and when Mike finds a slot, we'll either move to round 2 or final. I believe that most of the problems discussed in this thread have been solved by abstracting the terminology. I think it's better to not discuss further here as a summary has already been written. But please feel free to drop a comment on the new thread, when it is posted. Best regards, Stefanos
Oct 01
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 11 September 2019 at 02:02:58 UTC, Stefanos 
Baziotis wrote:
 [snip]

 Nonetheless, thank you very much for pointing it out! Either 
 it's part of this
 DIP or not.

 - Stefanos
No problem. ag0aep6g's comments above are also pretty spot on. I'm not a compiler expert or anything, so I didn't go through every little piece of the DIP initially in order to try to grok how it worked. I don't have a good sense of how the compiler currently resolves templates, so trying to understand how it worked in this specific case seemed like a big hill to climb. The reason why I was talking about the explicit template syntax is because it provides a lot of flexibility. When talking about Atila's concepts library above, the thing that is in the back of my mind is something like isInputRange (he provides an example in the Readme.md). One issue with passing an input range to a lot of phobos functions is that if you pass something that isn't an input range the error message isn't specific about why it isn't an input range. For instance, did you forget to define popFront? The concepts library helps provide better error messages in this case. However, it currently requires you to use models at the top of the struct in order to check this information. This requires the user to put models UDA before their own struct, rather than this happening at the point of the function. If we were able to do something like below, then the user does not need to put it on their own structs. I think that would make the concepts library much more powerful. template InputRange(T) { import concepts: models, isInputRange; static assert(models!(Foo, isInputRange)); alias InputRange = T; } void useInputRange(T)(InputRange!T foo) { }
Sep 11
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Wednesday, 11 September 2019 at 09:58:58 UTC, jmh530 wrote:
 I'm not a compiler expert or anything, so I didn't go through 
 every little piece of the DIP initially in order to try to grok 
 how it worked. I don't have a good sense of how the compiler 
 currently resolves templates, so trying to understand how it 
 worked in this specific case seemed like a big hill to climb.
For me, this DIP is the most complicated DIP I have seen - _just_ to handle alias declarations / instatiations in function arguments. And it already takes a lot of things for granted (i.e. the `Gen` function in the DIP is not specified). I would not have been able to complete it without some help from one of my professors. What I mean is that this is not necessarily the easiest thing to understand and even if it was, I'm not an expert in writing formal specifications. Regarding the implementation, well.. this a particularly draft implementation. :P It is after 3 days of first opening DMD.
 The reason why I was talking about the explicit template syntax 
 is because it provides a lot of flexibility.

 When talking about Atila's concepts library above, the thing 
 that is in the back of my mind is something like isInputRange 
 (he provides an example in the Readme.md). One issue with 
 passing an input range to a lot of phobos functions is that if 
 you pass something that isn't an input range the error message 
 isn't specific about why it isn't an input range. For instance, 
 did you forget to define popFront? The concepts library helps 
 provide better error messages in this case. However, it 
 currently requires you to use  models at the top of the struct 
 in order to check this information. This requires the user to 
 put models UDA before their own struct, rather than this 
 happening at the point of the function. If we were able to do 
 something like below, then the user does not need to put it on 
 their own structs. I think that would make the concepts library 
 much more powerful.

 template InputRange(T) {
     import concepts: models, isInputRange;
     static assert(models!(Foo, isInputRange));
     alias InputRange = T;
 }

 void useInputRange(T)(InputRange!T foo) {

 }
I understand the reasoning, yes. I also think it would be very beneficial. The problem is that throwing templates in general into the mix I think will make the DIP way complicated. Also, I don't think I will be able to derive a formal specification. Btw, IMHO, templates are in general under-specified. Both in D and C++. I might have missed something but to the best of my knowledge, they're constrained to intuitive descriptions and examples. Especially considering the C++'s `using`. And then it is left to the compiler implementor to get to a specific behavior. I tried this DIP to provide a formal specification for the subject. And I'm here to answer questions and receive corrections as I understand this is not necessarily the best formal specification ever. - Stefanos
Sep 11
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 11 September 2019 at 12:11:21 UTC, Stefanos 
Baziotis wrote:
 [snip]

 I understand the reasoning, yes. I also think it would be very 
 beneficial.
 The problem is that throwing templates in general into the mix 
 I think
 will make the DIP way complicated. Also, I don't think I will 
 be able
 to derive a formal specification.
Even if it's too complicated to support the use case I described above as part of this DIP, I still think this has a lot of value. Another reason I brought up that potential use case is that if it enabled that pattern then it might have helped convince Atila the DIP was a good idea if he could see the benefits with respect to one of his libraries.
 Btw, IMHO, templates are in general under-specified. Both in D 
 and C++.
 I might have missed something but to the best of my knowledge, 
 they're
 constrained to intuitive descriptions and examples. Especially 
 considering
 the C++'s `using`. And then it is left to the compiler 
 implementor
 to get to a specific behavior.
I'm sure people would appreciate any enhancements to the D specification.
Sep 11
parent reply Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Wednesday, 11 September 2019 at 12:47:45 UTC, jmh530 wrote:
 Even if it's too complicated to support the use case I 
 described above as part of this DIP, I still think this has a 
 lot of value.
I agree!
 Another reason I brought up that potential use case is that if 
 it enabled that pattern then it might have helped convince 
 Atila the DIP was a good idea if he could see the benefits with 
 respect to one of his libraries.
While that's probably true, IMO both parties (i.e. the DIP author and the reviewer) should act objectively. Meaning, a use case of a reviewer should be no different than another use case.
 I'm sure people would appreciate any enhancements to the D 
 specification.
I agree! I would for sure. And I think compiler implementors as well. - Stefanos
Sep 11
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 11 September 2019 at 15:36:04 UTC, Stefanos 
Baziotis wrote:
 [snip]

 While that's probably true, IMO both parties
 (i.e. the DIP author and the reviewer) should act objectively.
 Meaning, a use case of a reviewer should be no different
 than another use case.
On this PR thread [1], Atila said he struggled to see the value in it. My objective was to think up an example where he would see the value. I don't dispute that Atila both should and would act objectively in reviewing the DIP. However, if someone says they don't see value in something, it can be helpful to provide additional examples that might show the value. [1] https://github.com/dlang/dmd/pull/9778
Sep 11
parent Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Wednesday, 11 September 2019 at 15:52:18 UTC, jmh530 wrote:
 On this PR thread [1], Atila said he struggled to see the value 
 in it. My objective was to think up an example where he would 
 see the value. I don't dispute that Atila both should and would 
 act objectively in reviewing the DIP. However, if someone says 
 they don't see value in something, it can be helpful to provide 
 additional examples that might show the value.
Yes, thank you for that. I agree and I also assume that Atila will review this objectively. And if supporting this does not complicate the DIP significantly, it may as well be added. - Stefanos
Sep 11
prev sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Fri, Sep 6, 2019 at 2:34 PM Stefanos Baziotis via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 6 September 2019 at 12:17:11 UTC, rikki cattermole
 wrote:
 Your examples in abstract didn't look right.
 I ran the second to confirm my suspicion:

 onlineapp.d(9): Error: undefined identifier T
Could you paste the example that gave you this error? Btw, not all examples are compilable.
The issue is that your abstract is wrong. You have missed T For eg.: you have void templateFunction(TemplateType!T arg) { } instead of void templateFunction(T)(TemplateType!T arg) { }
Sep 06
parent Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Friday, 6 September 2019 at 21:05:41 UTC, Daniel Kozak wrote:
 The issue is that your abstract is wrong. You have missed T
 For eg.: you have void templateFunction(TemplateType!T arg) { }
 instead of void templateFunction(T)(TemplateType!T arg) { }
Yes, is was pointed out and acknowledged above. - Stefanos
Sep 06
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 6 September 2019 at 11:45:48 UTC, Mike Parker wrote:
 [snip]
Very happy to see this.
Sep 06