bearophile Wrote:
> I am about one year late for such comments or more. I also have some
> suggestions and questions.
>
> I suggest to perform a serch & replace in all the D2 documentation to replace
> all "invariant" with "immutable". Some versions of D2 from now "invariant"
> can be removed from DMD itself.
>
> -----------------
>
> From the examples of the docs. I hope to not see this code, it's not easy to
> understand:
> immutable(char*)** p = ...;
>
> -----------------
>
> >The const and immutable function attributes can also appear after the
> >closing parenthesis of the parameter list: <
>
> I think this doesn't produce much damage, but why?
>
> -----------------
>
> Mutable and transitive-immutable data types are easy to understand. But
> "const" is less easy to understand for me:
>
> >Const types are like immutable types, except that const forms a read-only
> >view of data. Other aliases to that same data may change it at any time.<
>
> Regarding its purpose the docs say just:
>
> >const finds applications in passing data through interfaces that promise not
> >to modify them.<
>
> I suggest to add more examples of "const" usage, to show where it can be
> useful, because I am not much able to understand where to use it.
>
> It may also be better to rename "const" of D2 as "constview" or "cview" then
> (and the meaning of const can be kept from D1).
>
> The semantic overloading of the "enum" keyword doesn't look nice, but it's
> not too much bad.
>
> -----------------
>
> The following things are written about constview/immutable member functions:
>
> immutable member functions are guaranteed that the object and anything
> referred to by the this reference is immutable. They are declared as:
>
> struct S {
> int x;
>
> immutable void foo() {
> x = 4; // error, x is immutable
> this.x = 4; // error, x is immutable
> }
> }
>
> constview member functions are functions that are not allowed to change any
> part of the object through the member function's this reference.
>
> I don't understand such explanations, and I'd like to see a bit wider
> example(s) about it.
>
> -----------------
>
> Immutable structs/classes can be quite useful, they are safer, remove some
> complexity from a program, they can be sometimes the right thing you want
> (think about a Date object that keeps one day of the year), help paralellism,
> and they may allow for other optimizations (for example there's no need to
> copy them (so you can save memory and/or allocations, just like for immutable
> strings), or on the opposite you can have a copy of them on each CPU cache,
> and you are sure they will not go out of sync, this allows for a program more
> scalable on multi-cores).
>
> So I have tried to write a very simple program that uses immutable structs
> and classes:
>
> immutable struct S {
> int x;
> this(int xx) { this.x = x; }
> }
>
> immutable class C {
> int x;
> this(int xx) { this.x = x; }
> }
>
> void main() {
> auto s = S(10);
> auto c = new C(10);
> }
>
>
> But the compiler outputs:
>
>
> Error: cannot implicitly convert expression (this) of type immutable(C) to
> test.C
> test.d(8): Error: constructor test.C.this missing initializer for final field
> x
> test.d(12): Error: constructor test.S.this (int xx) does not match parameter
> types (int)
> test.d(12): Error: ((immutable immutable(S) __ctmp1 = 0;
>
> ) , __ctmp1).this can only be called on a mutable object, not immutable(S)
>
>
> I don't understand such errors much. What is that I am doing wrong?
> Note that if you remove the "immutable" that program works, and if you
> replace "immutable" with "invariant" the compiler gives thye same errors
> (internally it keeps using immutable(C)).
>
> Thank you,
> bye,
> bearophile
Well, I'm glad it's just not me! Anytime I've used the keyword 'invariant' what
I get just won't compile. So I remove it, which suggests that from a practical
point of view, it is not much use.
Const for me should mean pretty much what it means in C++
If I write:
foo(const Bar b)
{
// I mean that if in my implementation of the function, I try to alter
// b, then the compiler should flag it as an error.
}
foo(invariant Bar b)
{
// Does not seem to offer anything else that I need!
}
