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;
}


-- 

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[]


-- 

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[]


-- 

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?


-- 

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.


-- 

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?


-- 

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.


-- 

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) { ... }


-- 

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.
Isn't unvariant implicitly castable to 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.
It adds dependency on argument, but how about dependency on the hidden argument - 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.
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.


-- 

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.
> 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.


--