www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1341] New: typeof(int) should probably be legal

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

           Summary: typeof(int) should probably be legal
           Product: D
           Version: 1.018
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: clugdbug yahoo.com.au


According to the spec (in declaration.html), the argument to typeof() must be
an expression. This is not currently enforced by DMD. In fact, it can be any
type, except for builtin types which fail with a misleading error message.

alias int foo;
typeof(foo) a; // ok
typeof(int) b; // FAILS: found ')' when expecting '.' following 'int'

typeof(typeof(foo)) c; // ok, even though the argument is obviously a type.

I think that the compiler's behaviour generally makes more sense than the spec
(and I'm finding it to be useful behaviour). Enforcing the rule in the spec
would mean the compiler would need to determine if 'foo' is a type name before
issuing a syntax error --> violation of independence of syntax and semantic
passes.

So I suggest that the spec be changed to allow typeof(Type) to be legal, and to
adjust the compiler to accept built-in types.
eg, make typeof(int) synonymous with int.


--
Jul 14 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com
           Keywords|                            |accepts-invalid, spec




------- Comment #1 from smjg iname.com  2007-10-21 10:58 -------
According to the spec, typeof(typeof(foo)) shouldn't compile.  As you've
probably noticed already, the syntax is

Typeof:
        typeof ( Expression )

and this is parseable only as a type and not as an expression.

I can see that there might be some generic programming use in defining
typeof(X) == X if X is already a type.  The only problem is that it isn't
documented.  But if what's in the brackets is already not parseable as an
Expression, there's no benefit to writing it this way.  As such, it's probably
reasonable to disallow it as it would mean yet another ambiguity in the
grammar.


--
Oct 21 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341





------- Comment #2 from bugzilla digitalmars.com  2008-07-02 01:41 -------
I agree with Stewart, neither should compile.


--
Jul 01 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341





------- Comment #3 from clugdbug yahoo.com.au  2008-07-02 02:10 -------
So the resolution would be that:

typeof(X)

would generate an error late in the semantic pass if X turns out to be a type,
rather than an expression?


--
Jul 02 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341





------- Comment #4 from bugzilla digitalmars.com  2008-07-02 02:44 -------
Yes.


--
Jul 02 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341





------- Comment #5 from clugdbug yahoo.com.au  2008-07-03 08:03 -------
One thing worries me about this...
in D1.0, a common metaprogramming idiom is "is(typeof(xxx))"

For example, this compiles in D1.0:
------
static assert(!is(typeof(nonexistent)));
------
Lots of code (including BLADE, for example) will fail if that stops working.
Please make sure that doesn't get broken in fixing this bug!


--
Jul 03 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341





------- Comment #6 from smjg iname.com  2008-07-03 09:03 -------
How do you work that out?


--
Jul 03 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|typeof(int) should probably |typeof(X) accepted, even if
                   |be legal                    |X is a type




------- Comment #7 from clugdbug yahoo.com.au  2008-07-03 09:46 -------
Changed the description of this bug in view of the discussion above.
The fear I mentioned above is probably irrational.


--
Jul 03 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #8 from clugdbug yahoo.com.au  2008-07-09 07:19 -------
Fixed DMD1.032


--
Jul 09 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aarti interia.pl




------- Comment #9 from clugdbug yahoo.com.au  2008-07-09 07:20 -------
*** Bug 1777 has been marked as a duplicate of this bug. ***


--
Jul 09 2008
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1341





------- Comment #10 from bugzilla digitalmars.com  2008-07-09 22:39 -------
Fixed dmd 1.032 and 2.016


--
Jul 09 2008