Community
Participate
Working Groups
The MOFM2T [let semantics is dangereously different to an OCL let. Accidentally assigning a Bag (from an implicit collect) to a Set is particularly easy and undiagnosed, just silent. Suggest: a) Provide a warning if the let initializer is not conformant to the let type. b) Provide some @nowarn annotation for users who rerally want to filter.
Hi Ed, We cannot go for a) as the let is clearly specified as would be an "if - oclIsKindOf" (or "if - instanceof" if talking Java); it is expected that the specified type might not match the right operand value, in which case we switch to the "elselet" or ignore the let block altogether. However the evaluation engine's runtime checks might not be enough if you say we do allow for the assignment of a Bag to a Set-typed variable. I'll try and check that.
The behaviour is entirely correct (specification-wise) but unhelpful (user-wise). An attempt to assign a Bag to a Set does not succeed. It would be nice to have a warning that this guaranteed failure has been requested.
I see now... but adding a warning that the user wouldn't be able to get rid of (if it is what he requested)? Do you have examples of what you would like reported as warning as compared to what you would allow unreported (as far as Set and Bag are concerned)?
I suggested a nowarn annotation for when the user knows that the warning is wrong c.f. Java allows you to do all sorts of stupid things post-suppressWarnings. Thinking about this a bit more, this may be an Acceleo bug after all. An 'Unreachable match' (analoguous to an unreachable if branch in Java) occurs whenever the source type is incompatible with a target type. These errors are mostly diagnosed, except implicit filters ([let, [for). So whenever the collection kind is different (unless target is Collection itself), the match is dead, and if one element type does not conform to the other element type the match is dead.
Indeed, I can see how such a warning would be useful... and in fact I too come to wonder whether we really need a @nowarn annotation in these cases. We'll need to put some thought in this.
Created attachment 178741 [details] Patch v1.0
Contributed and available in Acceleo 3.1.0 M2
