D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 869 - Cast of a parenthesized expression combined with !is is mistaken for a C style cast and a template specialization
Summary: Cast of a parenthesized expression combined with !is is mistaken for a C styl...
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D1 (retired)
Hardware: x86 Windows
: P3 minor
Assignee: No Owner
URL:
Keywords: patch, rejects-valid, spec
Depends on:
Blocks:
 
Reported: 2007-01-21 08:42 UTC by Matti Niemenmaa
Modified: 2014-02-15 13:13 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Matti Niemenmaa 2007-01-21 08:42:04 UTC
static assert (cast(int)(foo) !is null);
// or with normal assert:
void main() { assert (cast(int)(foo) !is null); }

The above code snippet produces, for both lines 1 and 3, the following pair of errors:

(type identifier : specialization) expected following is
C style cast illegal, use cast(foo)!0

It's easy to work around: either remove the parentheses around foo or add another pair of them, whichever is appropriate for the expression.
Comment 1 Thomas Kühne 2007-01-23 07:46:18 UTC
http://www.digitalmars.com/d/overview.html
>D retains C operators and their precedence rules, order of evaluation rules, 
and promotion rules.

As C hasn't got an "!is" operator it is impossible to decide how this code 
should be interpreted:
# 
# cast(int)(foo !is null) // 1
# (cast(int)foo) !is null // 2
#
Comment 2 Christian Kamm 2009-06-30 10:33:34 UTC
DMD 1.045 digests the following test case without complaint:

class C {}
C foo;
void main() {
  assert (cast(Object)(foo) !is null);
}

To resolve this issue, add the following line to "Identity Expressions":

The is and !is expressions have the same precedence as the equality expressions == and !=.
Comment 3 Don 2009-12-15 14:22:17 UTC
This was fixed between 1.030 and 1.036.
No spec change is required (precedence is implied in the BNF descriptions).