class A
{
private int[] Xrg;
int[] rg() const
{
return Xrg;
}
}
void f(invariant A a)
{
a.rg[0]=0;
}
Comment #1 by dfj1esp02 — 2008-06-17T09:40:19Z
C++ solution: forces rg to have return type const int[]
Comment #2 by 2korden — 2008-06-17T09:54:55Z
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[]
Comment #3 by dfj1esp02 — 2008-06-18T02:09:01Z
So one should write two getters: const and non-const?
Comment #4 by wbaxter — 2008-06-18T05:28:49Z
(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.
Comment #5 by 2korden — 2008-06-18T06:11:08Z
Shall we close this one?
Comment #6 by braddr — 2008-06-18T11:18:12Z
No. invariantness if f's arg isn't being preserved, so this is a hole that Walter should see. I've reopened.
Comment #7 by wbaxter — 2008-06-19T01:05:18Z
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) { ... }
Comment #8 by dfj1esp02 — 2008-06-19T02:42:59Z
(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.
Comment #9 by wbaxter — 2008-06-19T07:19:25Z
(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.
Comment #10 by schveiguy — 2008-10-06T18:55:43Z
(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
Comment #11 by dfj1esp02 — 2008-10-07T02:17:24Z
we expect to get invariant data from invariant object.
Comment #12 by schveiguy — 2008-10-07T08:40:52Z
(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.