Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

semantics with statics and prefixes #10

Open
sigmundch opened this issue May 18, 2015 · 1 comment
Open

semantics with statics and prefixes #10

sigmundch opened this issue May 18, 2015 · 1 comment

Comments

@sigmundch
Copy link

The current semantics of exp?.x are described in terms of evaluating this:

((a) => a == null ? null : a.x)(exp)

Because static fields cannot be read as instance members, this implies that we cannot use ?. with statics. Similarly, because we don't have first class libraries, we cannot use ?. with prefixes either.

This seems to match what the 07 test in conditional_property_access_test.dart checks, but I wanted to confirm before I implement this in dart2js.

This surprised me a little bit though. I was expecting that C?.x would be valid, it would issue a warning (e.g. "null-aware operators are not useful with statics"), but would otherwise execute as if the user had written C.x.

@gbracha @stereotype441 - what are your thoughts on switching to the latter?

@stereotype441
Copy link

I can see arguments either way. The current spec has the advantage of consistency (prefixes and class names have special meaning only when followed by .; adding special cases for ?. seems silly, especially given that it doesn't afford the user any extra expressiveness). On the other hand, it seems equally silly to write extra code to prohibit C?.x and prefix?.x when it's pretty obvious what the user probably meant.

But I really don't have strong feelings about it; it seems unlikely that anyone would write C?.x or prefix?.x on purpose, since neither prefixes nor class literals can ever be null. So it probably doesn't matter.

If I had to make the call I would probably lean toward leaving it as is just out of laziness :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants