Skip to content

Proposal: Disallow e is null and other constant patterns #15539

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

Closed
alrz opened this issue Nov 26, 2016 · 8 comments
Closed

Proposal: Disallow e is null and other constant patterns #15539

alrz opened this issue Nov 26, 2016 · 8 comments
Assignees
Labels
Area-Language Design Bug Resolution-By Design The behavior reported in the issue matches the current design
Milestone

Comments

@alrz
Copy link
Member

alrz commented Nov 26, 2016

e is null is a good way for reference null check instead of (object)e == null but it does not work with non-constant expressions e.g. e1 is e2. I think multiple ways of doing the same thing would be (1) confusing for beginners and (2) it would cause yet another inconsistency all over the code base i.e. there should be a code style option to prefer one over the other. I'd rather have a dedicated operator for such operations (#8409) to cover all cases and maintain a consistent behavior instead of an operator that does not cover all cases and essentially is useful in comparing by value scenarios i.e. patterns.

If it's here to stay I'd like to hear the rational behind it.

@ViIvanov
Copy link

e is null can not be used for reference comparisons because it uses the Object::Equals(object, object) sample

@alrz
Copy link
Member Author

alrz commented Nov 26, 2016

Currently all constant patterns generate that call. It's just not optimized yet. See #13247.

@ViIvanov
Copy link

Thanks, nice catch.

@alrz
Copy link
Member Author

alrz commented Nov 27, 2016

Closing per #8409 (comment) as it's the intended usage and probably #8409 would be a non-issue.

@alrz alrz closed this as completed Nov 27, 2016
@alrz
Copy link
Member Author

alrz commented Nov 27, 2016

I think I closed this prematurely, because still I couldn't think of any good reason to permit constant patterns directly in top level is e.g. e is 3. I believe it's just a syntax variation for e == 3 and may cause unnecessary inconsistencies.

@gafter
Copy link
Member

gafter commented Nov 28, 2016

@MadsTorgersen I propose we discuss this (disallowing constant patterns on the right of the is operator) at an upcoming LDM.

@alrz e is 3 is not the same as e == 3, as it can work even when the type of e is object.

@Neme12
Copy link
Contributor

Neme12 commented Nov 29, 2016

Agreed 100%. To me this not only seems like unnecessary complexity, confusion for beginners, more inconsistency and ways to do essentially the same thing, but also like abuse of the is operator which has always meant instanceof in C#, and never any kind of comparison.

@gafter
Copy link
Member

gafter commented Dec 1, 2016

The LDM discussed this yesterday and concluded that we intend to support constant patterns in the is operator. The idiom e is null is useful and much nicer than the current alternative (object)e == null.

@gafter gafter closed this as completed Dec 1, 2016
@gafter gafter added the Resolution-By Design The behavior reported in the issue matches the current design label Dec 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Language Design Bug Resolution-By Design The behavior reported in the issue matches the current design
Projects
None yet
Development

No branches or pull requests

5 participants