Community
Participate
Working Groups
Recently I tried the nice concept of null-safe feature calls: o?.f The Xtend2 validator seemed content, but then the Java compiler complained about this (quoted from memory): (o == null ? (boolean)null : o.getF()) Maybe this should be detected a bit earlier in the pipeline? :)
I assume the expression o?.f was used in a context where a boolean was expected?
(In reply to comment #1) > I assume the expression o?.f was used in a context where a boolean was > expected? I don't remember the exact situation, but yes, "if (o?.f)" is a good way to reproduce. BTW: in comment 0 I spoke of detecting an error earlier in the pipeline, but now I wonder whether it shouldn't actually be supported? if (o?.f) is just much more convenient than the omnipresent if (o != null && o.f) I think it would be obvious, that o == null renders the whole expression false, no? I realize that this would require special handling of boolean, because the same pattern wouldn't be equally obvious for other basic types. E.g., what's the valua of o?.c if the expected type is char and o == null? Doesn't make much sense probably.
This one was already fixed.
(In reply to comment #3) > This one was already fixed. Great. Fixed as in "error is now reported" or as in "creates valid code now"? On a similar note just the other day I saw code produced by the xtend2 compiler that looked something like: if (new Integer(val) == null) (again quoted from memory but I hope you get the idea). Not quite as bad, but why bother to compile (and test) code that's so obviously wrong? I know basic types in Java are a pita but your users will thank you if you catch more bogus programs and report what's wrong.
(In reply to comment #4) > (In reply to comment #3) > > This one was already fixed. > > Great. > Fixed as in "error is now reported" or as in "creates valid code now"? Fixed as in "creates valid code now". > On a similar note just the other day I saw code produced by the > xtend2 compiler that looked something like: > > if (new Integer(val) == null) > > (again quoted from memory but I hope you get the idea). > > Not quite as bad, but why bother to compile (and test) code that's > so obviously wrong? > > I know basic types in Java are a pita but your users will thank you > if you catch more bogus programs and report what's wrong. Equalitiy is checked by means of ObjectExtensions.operator_equals by default but clients are allowed to provide other implemenations. Currently we don't have concrete plans to allow for optimizated compiler strategies for such extension methods.
Closing all bugs that were set to RESOLVED before Neon.0
