www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5286] New: To avoid a problem with Template syntax

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5286

           Summary: To avoid a problem with Template syntax
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: diagnostic
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 28 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5286


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |WONTFIX



19:53:38 PST ---
I don't agree it is a source of confusion. I don't know anyone who has been
confused by it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5286




19:57:37 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5286


nfxjfg gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nfxjfg gmail.com





 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5286






 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.




 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_;
    }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5286




22:16:09 PST ---


 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 01 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5286


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 02 2010