Benji Smith wrote:
Daniel Keep wrote:
Benji Smith wrote:
Don wrote:
Denis Koroskin wrote:
Foo nonNull = new Foo();
Foo? possiblyNull = null;
>
Wouldn't this cause ambiguity with the "?:" operator?
At first, thought you might be right, and that there would some
ambiguity calling constructors of nullable classes (especially given
optional parentheses).
But for the life of me, I couldn't come up with a truly ambiguous
example, that couldn't be resolved with an extra token or two of
lookahead.
The '?' nullable-type operator is only used in type declarations,
not in expressions, and the '?:' operator always consumes a few
trailing expressions.
Also (at least in C#) the null-coalesce operator (which converts
nullable objects to either a non-null instance or a default value)
looks like this:
MyClass? myNullableObj = getNullableFromSomewhere();
MyClass myNonNullObj = myNullableObj ?? DEFAULT_VALUE;
Since the double-hook is a single token, it's also unambiguous to parse.
--benji
Disclaimer: I'm not an expert on compilers. Plus, I just got up. :P
The key is that the parser has to know what "MyClass" means before it
can figure out what the "?" is for; that's why it's context-dependant.
D avoids this dependency between compilation stages, because it
complicates the compiler. When the parser sees "MyClass", it *doesn't
know* that it's a type, so it can't distinguish between a nullable
type and an invalid ?: expression.
At least, I think that's how it works; someone feel free to correct me
if it's not. :P
-- Daniel
I could be wrong too. I've done a fair bit of this stuff, but I'm no
expert either :)
Nevertheless, I still don't think there's any ambiguity, as long as the
parser can perform syntactic lookahead predicates. The grammar would
look something like this:
DECLARATION :=
IDENTIFIER // Type name
( HOOK )? // Is nullable?
IDENTIFIER // Var name
(
SEMICOLON // End of declaration
|
(
OP_ASSIGN // Assignment operator
EXPRESSION // Assigned value
)
)
Whereas the ternary expression grammar would look something like this:
TERNARY_EXPRESSION :=
IDENTIFIER // Type name
HOOK // Start of '?:' operator
EXPRESSION // Value if true
COLON // End of '?:' operator
EXPRESSION // Value if false
The only potential ambiguity arises because the "value if true"
expression could also just be an identifier. But if the parser can
construct syntactic predicates to perform LL(k) lookahead with arbitrary
k, then it can just keep consuming tokens until it finds either a
SEMICOLON, an OP_ASSIGN, or a COLON (potentially, recursively, if it
encounters another identifier and hook within the expression).
Still, though, once it finds one of those tokens, the syntax has been
successfully disambiguated, without resorting to a semantic predicate.
It requires arbitrary lookahead, but it can be done within a
context-free grammar, and all within the syntax-processing portion of
the parser.
Of course, I could be completely wrong too :)
--benji
case a?.b:c:
break;
is this
case ((a?).b):
c:
break;
or is it
case (a ? b : c ) :
break;
