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





------- Comment #1 from terranium yandex.ru  2008-06-17 09:40 -------
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





------- Comment #2 from 2korden gmail.com  2008-06-17 09:54 -------
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





------- Comment #3 from terranium yandex.ru  2008-06-18 02:09 -------
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





------- Comment #4 from wbaxter gmail.com  2008-06-18 05:28 -------
(In reply to comment #3)
 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




------- Comment #5 from 2korden gmail.com  2008-06-18 06:11 -------
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                     |




------- Comment #6 from braddr puremagic.com  2008-06-18 11:18 -------
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





------- Comment #7 from wbaxter gmail.com  2008-06-19 01:05 -------
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





------- Comment #8 from terranium yandex.ru  2008-06-19 02:42 -------
(In reply to comment #4)
 But in D you may need three, actually.  invariant, const, and non-const.

(In reply to comment #7)
 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.  

- this. (In reply to comment #6)
 No.  invariantness if f's arg isn't being preserved, so this is a hole that
 Walter should see.  I've reopened.

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





------- Comment #9 from wbaxter gmail.com  2008-06-19 07:19 -------
(In reply to comment #8)
 (In reply to comment #4)
 But in D you may need three, actually.  invariant, const, and non-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





------- Comment #10 from schveiguy yahoo.com  2008-10-06 18:55 -------
(In reply to comment #6)
 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





------- Comment #11 from terranium yandex.ru  2008-10-07 02:17 -------
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





------- Comment #12 from schveiguy yahoo.com  2008-10-07 08:40 -------
(In reply to comment #11)
 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




------- Comment #13 from terranium yandex.ru  2008-10-08 11:54 -------
As you insist, I extracted RFE to bug 2400.


-- 
Oct 08 2008