Google's Go

[Lars T. Kyllingstad]

Steven Schveighoffer wrote:
> On Sun, 24 Jan 2010 04:25:21 -0500, grauzone <none at example.net> wrote:
> 
>> Or how inout(T) isn't just a shortcut to avoid writing 
>> const/immutable-aware code 3 times or putting it into a template?
> 
> The benefits are:
> 
> - Single implementation where all that is different is the type 
> qualifier.  (also allows the function to be virtual)
> - No propogation of contract through an accessor.  In other words, using 
> an inout accessor on an object or struct does not alter the caller's 
> contract with the data itself.
> 
> The latter function is almost essential for properties, for without such 
> a mechanism, you are forced to write your property definitions in 
> triplicate.
> 
> i.e.
> 
> class C {}
> 
> struct S
> {
>    C c;
> }
> 
> immutable s1 = S(new C);
> S s2 = S(new C);
> 
> immutable c1 = s1.c;
> C c2 = s2.c;
> 
> Now, change S.c into a property.
> 
> The first line of thinking is, "well, accessing c doesn't change the 
> object itself, so it should be const."  But that means you must return a 
> const(C), so it breaks defining c1 and c2 (can't assign immutable or 
> mutable from const).
> 
> So, you say, "I'll just define it without const," but then you can't 
> call the property unless S is a mutable type, so that only works in c2's 
> case
> 
> Maybe you think you can get away with just mutable and immutable, but 
> again, it doesn't work if the whole object is const, since you can't 
> call either function from there.
> 
> Templates won't work here, you cannot template the 'this' pointer.  So 
> you end up with 3 identical implementations, and *no* const guarantee on 
> the mutable one:
> 
> @property C c() { return _c; }
> @property const(C) c() const { return _c; }
> @property immutable(C) c() immutable { return _c; }


Out of curiosity:  How does inout(T) fix this?  I thought inout was all 
about transporting the const-ness of the input type to the return type, 
and in this example there are no input parameters.

-Lars