PR# 15145 Self-initializing attribute with INTEGER type does not work

A class that prints the value of a self-initializing attribute declared as

        n: INTEGER
                attribute
                        Result := 47
                end

prints 0 when system is executed, instead of 47.  Maybe this isn't implemented
yet.

Compile with attached class and config file.
Execute system.  Prints 0 instead of 47.

Thank you for your report. The message is fixed to report Warning in rev#88431 of EiffelStudio 7.1 intermediate release.

This is almost fixed, but when I execute the associated test exec296 the
compiler says (in 7.1.88368):

Error code: VWAB

Warning: attribute body is never executed because the type of the attribute is self-initializing (i.e. expanded or detachable).

Shouldn't that be "Warning code", since this is just a warning?

If I have missed something and this is intentional, please close this.

Fixed in rev#88350 of EiffelStudio 7.1 intermediate release.

OK, I think we agree that a warning is the appropriate behavior for
the compiler in this case.  The "output" file for eweasel test exec296 is
correct, but the tcf file will need to be adjusted to account for the warning.

Actually I don't agree with this. The body of the attribute should be executed if not yet initialized and if the type has not default value. An expanded type has a default value thus it will never be called.

What we should do is produce a warning when such code appears because it is quite troubling when it does not do what you expected it to do.

Since Manu agreed with me that the compiler should report an
error (or at least a warning) in a void-safe system for thie code:

   weasel: INTEGER
      attribute
         Result := 47
      end

I am reopening this report.  If you change this, the tcf for eweasel
test exec296 will need to be adjusted.

I thought an explicit attribute body would always be executed if the 
attribute value was referenced before any explicit assignments to the
attribute.  In other words, I thought that the explicit body took precedence
over the default value.  Evidently, that is not the case.  I wasn't part of
the discussions on this issue, so I hope there are good reasons for this
decision.  The way it currently works seems wrong to me.  Please discuss this
with the ECMA committee if not already hashed out in detail and if you feel
it is appropriate.

I agree with David on this point. We should simply disallow attribute body that are for sure never going to be executed.

I'm sure you are more familiar with the ECMA standard than I am, so undoubtedly
you are right.  I would just like to say that from a user perspective this is
incrediby confusing.  It sounds like you are saying that the code in the
attribute body is dead code if the attribute type is INTEGER.  Perhaps there is
something subtle I am missing here, but shouldn't the compiler report an error
or at least warn me if I am writing code that can never be executed?
It certainly isn't obvious to me.

A self-initializing attribute body is executed when other attribute initialization methods are not applied: explicit attribute setting and default initialization of expanded types. For INTEGER there is no need to execute it because it is known how to initialize the attribute (by setting its value to 0).

Added eweasel test exec296 for this bug.

Attachments for problem report #15145