www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1604] New: Non-final method on final struct is too restrictive

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604

           Summary: Non-final method on final struct is too restrictive
           Product: D
           Version: 2.007
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: andrei metalanguage.com


Currently, code like:

foreach (e; array)
{
  e.function();
}

fails with the message "Error: cannot call mutable method on final struct" if
function is not const. But function can modify data indirectly referenced by e,
so the restriction is not justified. 

Suggested fix: lift that restriction for now. In the future, if function's
source is available, issue an error if and only if function does not use the
object as an rvalue.


--
Oct 20 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com




------- Comment #1 from smjg iname.com  2008-09-09 15:06 -------
On second thoughts ... is this really rejects-valid, or is it an enhancement
request?  I guess I need to learn a bit more about how const functions work....


--
Sep 09 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604


brunodomedeiros+bugz gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brunodomedeiros+bugz gmail.c
                   |                            |om




------- Comment #2 from brunodomedeiros+bugz gmail.com  2008-09-11 05:13 -------
Yes, it seems to me that this is according to current const semantics, so it
would not be a rejects-invalid.

Is 'e' a struct or an object? (or any, doesn't matter?)
And... doesn't this sugestion introduce a fundamental hole in the const system?
How will the compiler know that the developer intended 'function' to not-change
just the rvalue of the 'e' param, instead of not-changing any of the
objects/data accessible by the 'e' param, which is what the traditional meaning
of const is (fully transitive).
And what if the source code for 'function' is not available at all?...

Perhaps it's time to revisit the ideia of allowing logical const...


--
Sep 11 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
           Keywords|rejects-valid               |




------- Comment #3 from smjg iname.com  2008-09-11 10:07 -------
I'm somewhat confused.  Firstly, all documentation of final as a storage class
seems to have vanished, apart from the seemingly orphaned page
http://www.digitalmars.com/d/final-const-invariant.html

Secondly, that page and the current page
http://www.digitalmars.com/d/2.0/const3.html
alike state

"Const member functions are functions that are not allowed to change any part
of the object through the member function's this reference."

Nothing about changing other data pointed to through the object.  Thus const
functions semantically match the final storage class, and invariant functions
semantically match the const storage class.  (DMD 2.019 doesn't seem to
implement it correctly though - but that's another matter.)  Thus according to
the current spec, if the function doesn't modify anything through this, it
should be declared as invariant, rather than const.  No need for the compiler
to second-guess by examining the function source.  So according to this
principle, the callability rules should be:

|        function is ->  mutable  const  invariant
v this is
mutable                  yes      yes    yes
final                    no       yes    yes
const                    no       yes    yes
invariant                no       yes    yes

I'm not sure what was actually intended.  Really, const, final and invariant
should all be available as function storage classes, and match the .  The
problem is that final as a function attribute is already taken, but that
shouldn't stop it working with "final" placed between the parameter list and
the '{'.  By this, the callability rules would be

|        function is ->  mutable  final  const  invariant
v this is
mutable                  yes      yes    yes    no
final                    no       yes    yes    no
const                    no       no     yes    no
invariant                no       no     yes    yes

What should we do?


--
Sep 11 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604





------- Comment #4 from smjg iname.com  2008-09-11 10:08 -------

 Really, const, final and invariant
 should all be available as function storage classes, and match the .


Not sure what happened there.  Let's try again:

Really, const, final and invariant should all be available as function storage
classes, and match the semantics of the corresponding storage classes of this.


--
Sep 11 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604





------- Comment #5 from smjg iname.com  2008-09-11 10:50 -------
Indeed, as I try it now, the compiler doesn't even seem to accept declaring a
variable as final anywhere.  Strange - there's nothing in the changelog about
this being removed.


--
Sep 11 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604





------- Comment #6 from brunodomedeiros+bugz gmail.com  2008-09-12 05:39 -------
(In reply to comment #5)

 Indeed, as I try it now, the compiler doesn't even seem to accept declaring a
 variable as final anywhere.  Strange - there's nothing in the changelog about
 this being removed.
 


Yes, there wasn't anything in the changelog, but 'final' (and any equivalent
concept) was removed from D2 when the new const system was introduced.


--
Sep 12 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604





------- Comment #7 from smjg iname.com  2008-09-12 06:43 -------
So this issue is basically obsolete now.

Still, I'm confused.  What are the basic differences between the new const
system and the old one, other than the nonexistence of final?


--
Sep 12 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604





------- Comment #8 from brunodomedeiros+bugz gmail.com  2008-09-19 08:53 -------
(In reply to comment #7)

 So this issue is basically obsolete now.
 


Err, I don't think the original issue of this bug submitted by Andrei is
obsolote, although I was still trying to figure out what exactly he ment.


 Still, I'm confused.  What are the basic differences between the new const
 system and the old one, other than the nonexistence of final?
 


You can read about D2 const here: http://www.digitalmars.com/d/2.0/const3.html
Don't try to compare to the D1 system, it's way different, so it's better to
take a fresh start.


--
Sep 19 2008
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604





------- Comment #9 from smjg iname.com  2008-09-22 08:31 -------
(In reply to comment #8)

 You can read about D2 const here: http://www.digitalmars.com/d/2.0/const3.html
 Don't try to compare to the D1 system, it's way different, so it's better to
 take a fresh start.


You seem to have got things confused.  final wasn't part of any D1 const
system.  My query was about the differences between the current D2 const system
and the two previous D2 const systems (2.008 and 2.000-2.007, if the changelog
is to go by).  We really need a side-by-side comparison, for both historical
and practical interest.


--
Sep 22 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
d-bugmail puremagic.com wrote:

 http://d.puremagic.com/issues/show_bug.cgi?id=1604
 
 
 
 
 
 ------- Comment #9 from smjg iname.com  2008-09-22 08:31 -------
 (In reply to comment #8)

 You can read about D2 const here: http://www.digitalmars.com/d/2.0/const3.html
 Don't try to compare to the D1 system, it's way different, so it's better to
 take a fresh start.


 
 You seem to have got things confused.  final wasn't part of any D1 const
 system.  My query was about the differences between the current D2 const system
 and the two previous D2 const systems (2.008 and 2.000-2.007, if the changelog
 is to go by).  We really need a side-by-side comparison, for both historical
 and practical interest.
 
 


Oops, my bad. I don't recall the other previous const systems, as there 
was lots of confusion then. I myself got some of the previous iterations 
confused with each other.
So, I would still say it's probably best to just take a fresh look.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 24 2008
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1604


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #10 from Andrei Alexandrescu <andrei metalanguage.com>  2009-08-24
22:21:46 PDT ---
Obsoleted by the elimination of final values.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 24 2009