Bug 5286 – To avoid a problem with Template syntax

Status
RESOLVED
Resolution
WONTFIX
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2010-11-28T15:14:00Z
Last change time
2010-12-02T01:01:19Z
Keywords
diagnostic
Assigned to
nobody
Creator
bearophile_hugs

Comments

Comment #0 by bearophile_hugs — 2010-11-28T15:14:06Z
D has removed some cases of bug-prone C syntax, like: int main() { int* ptr1, ptr2; return 0; } But D must avoid introducing new ones. D2 has introduced a handy shortcut to define templates, but this shortcut must not cause ambiguity for the eyes of the programmer that reads the code (I don't care if the syntax is perfectly defined for the D compiler, here I am talking about human users and their fallible nature. Because the same was true for some C syntax too, that is well defined for the compiler). So to avoid troubles this code raises a syntax error, this is good: struct Foo(T) {} Foo!Foo!int y; void main() {} test.d(2): multiple ! arguments are not allowed But this D2 code too may be ambiguous for the person that reads it: struct Foo(T) {} Foo!int* x; static assert(!is(typeof(x) == Foo!(int*))); static assert(is(typeof(x) == Foo!(int)*)); void main() {} In similar situations I'd like D to require parentheses (so "Foo!int* x;" becomes a syntax error), so the programmer must write: Foo!(int*) or: Foo!(int)* And this possible source of confusion for the person that reads the code is avoided.
Comment #1 by bugzilla — 2010-11-29T19:53:38Z
I don't agree it is a source of confusion. I don't know anyone who has been confused by it.
Comment #2 by bugzilla — 2010-11-29T19:57:37Z
I should add that in cases like this, one should be able to document a trail of confusion, such as is well known with (a & b || c). The point of operator precedence is to avoid requiring parentheses everywhere, so a reasonably compelling case has to be presented to require them.
Comment #3 by nfxjfg — 2010-11-30T00:56:14Z
(In reply to comment #1) > I don't agree it is a source of confusion. I don't know anyone who has been > confused by it. But I do. I know lots of people that have come to me with this problem, saying it made them almost not use D.
Comment #4 by bearophile_hugs — 2010-11-30T05:08:50Z
(In reply to comment #1) > I don't agree it is a source of confusion. I don't know anyone who has been > confused by it. Me! I'm the first then. (In reply to comment #2) > I should add that in cases like this, one should be able to document a trail of > confusion, such as is well known with (a & b || c). The D2 template instantiation syntax is present in D2 only, and only for few months. So there is no 30 years old series of bug examples like the C syntax (a & b || c). Something similar is true for the new D2 operator syntax, that I think is bug-prone because it doesn't enforce statically only the allowed operators. So if you ask for a long trail of documented bugs you will need several years of D2 bugs, and then it may be too much late to fix D2 syntax. So my suggestion is to be more careful right now, because there is no better alternative. Here is some documentation, I have had a bug caused by the !x D2 template syntax in a program that defines a template linked list node: struct Node(T) { T data; Node!(T)* next; this(T data_, Node!(T)* next_=null) { data = data_; next = next_; } }
Comment #5 by bugzilla — 2010-12-01T22:16:09Z
(In reply to comment #3) > But I do. I know lots of people that have come to me with this problem, saying > it made them almost not use D. I'd like more information on this, please. There's been nothing on the ng.
Comment #6 by clugdbug — 2010-12-02T01:01:19Z
This bug report is actually asking for the non-parentheses template instantiation to be discarded entirely. It is a feature which relies 100% on the precedence rules. Remember that templates can have value parameters, so even something like: int y; auto x = to!Foo(y); can be considered to be ambiguous. Is it: to!(Foo)(y) or to!(Foo(y)) This applies to ALL function templates. The idea that there are a few "ambiguous cases" which could generate errors, is completely wrong.