www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2094] New: transitive const can be broken easily

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

           Summary: transitive const can be broken easily
           Product: D
           Version: 2.012
          Platform: PC
               URL: http://www.digitalmars.com/webnews/newsgroups.php?art_gr
                    oup=digitalmars.D&article_id=71465
        OS/Version: Windows
            Status: NEW
          Keywords: spec
          Severity: normal
          Priority: P2
         Component: www.digitalmars.com
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: terranium yandex.ru


class A
{
        private int[] Xrg;

        int[] rg() const
        {
                return Xrg;
        }
}

void f(invariant A a)
{
        a.rg[0]=0;
}


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






C++ solution: forces rg to have return type const int[]


--
Jun 17 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094






It shouldn't be able to compile and in fact it doesn't (tested with DMD2.013):
Error: cannot implicitly convert expression (this.Xrg) of type const(int[]) to
int[]


--
Jun 17 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094






So one should write two getters: const and non-const?


--
Jun 18 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094








 So one should write two getters: const and non-const?
 


That's generally how it's done in C++, yes.
But in D you may need three, actually.  invariant, const, and non-const.
There was much discussion about creating some rules so that D doesn't require
that kind of repetition, but Walter never gave any of the ideas a nod as far as
I know.


--
Jun 18 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094


2korden gmail.com changed:

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





Shall we close this one?


--
Jun 18 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094


braddr puremagic.com changed:

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





No.  invariantness if f's arg isn't being preserved, so this is a hole that
Walter should see.  I've reopened.


--
Jun 18 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094






I was just browsing through WalterAndrei.pdf from last year's D conference,
when I noticed the "return" storage class.  I had forgotten about that one.  

So I was wrong about Walter not having endorsed any particular solution to the
redundant const methods problem.  The solution he proposed at the D conference
was to have something like:

   const(char[]) capitalize(return const(char[]) s) { ... }


--
Jun 18 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094








 But in D you may need three, actually.  invariant, const, and non-const.


Isn't unvariant implicitly castable to const?



 I was just browsing through WalterAndrei.pdf from last year's D conference,
 when I noticed the "return" storage class.  I had forgotten about that one.  


It adds dependency on argument, but how about dependency on the hidden argument
- this.



 No.  invariantness if f's arg isn't being preserved, so this is a hole that
 Walter should see.  I've reopened.


I think, if my sample doesn't compile, this bugreport is no longer valid or
severity could be canged to RFE, I'm not sure, what you want.


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










 But in D you may need three, actually.  invariant, const, and non-const.


 Isn't unvariant implicitly castable to const?


If you're hoping to be able to assign the result to an invariant then you'll
need an invariant flavor of it.


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








 No.  invariantness if f's arg isn't being preserved, so this is a hole that
 Walter should see.  I've reopened.
 


I don't see how that matters.  You should be able to call const functions on an
invariant object.  Note that the submitted code doesn't actually compile.

As an aside, the scoped const proposal I made would solve the 3 versions of a
function requirement.

http://d.puremagic.com/issues/show_bug.cgi?id=1961


--
Oct 06 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094






we expect to get invariant data from invariant object.


--
Oct 07 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094








 we expect to get invariant data from invariant object.


Then define an invariant function.  Const is the equalizer, and it's perfectly
acceptable to get invariant data as const.  All const means is that the
function will not modify the data, and will not return anything but const
references to the data.  It doesn't mean that if the data is invariant, the
function magically returns invariant.

I don't see how this bug is valid.


--
Oct 07 2008
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2094


terranium yandex.ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED





As you insist, I extracted RFE to bug 2400.


--
Oct 08 2008