I'm mainly coming from languages that haven't got structs, let alone the kind of differentiation D offers between mutable/immutable/const/etc variables, so I'm still trying to work out just when to use each - What's different between these two examples, practically speaking? When would you use one over the other?

struct thing1{
    const int x, y;
}

struct thing2{
    int x, y;
}

Thanks!

On 09.04.2016 18:07, pineapple wrote:
> What's different between these two examples, practically speaking? When
> would you use one over the other?
>
> struct thing1{
>      const int x, y;
> }
>
> struct thing2{
>      int x, y;
> }

In this case, const is practically the same as immutable. But immutable is the stricter qualifier. It's more self-documenting, and it may be simpler to utilize for the compiler in terms of optimizations. So I'd use immutable instead of const here. Differences between const and immutable manifest with indirections (pointers, arrays, classes, ...).

The effect of const (or immutable) in thing1 is simple: you can't mutate its x or y after construction. Whereas thing2 allows mutation of its x and y.

In code:
----
thing1 t1;
t1 = thing1(1, 2); /* doesn't compile; the fields of t1 are immutable */

thing2 t2;
t2 = thing2(1, 2); /* compiles */
----

You can do the same with thing2 on a per-object basis:
----
immutable thing2 t2i;
t2i = thing2(1, 2); /* doesn't compile; t2 is immutable */
----

For a struct like thing1 that just has some value type members, I don't see a point in making all the members const/immutable. Making the instances const/immutable instead is more versatile.

const is generally more useful when references are involved (pointers, arrays, classes, ...).

On Saturday, April 09, 2016 16:07:36 pineapple via Digitalmars-d-learn wrote:
> I'm mainly coming from languages that haven't got structs, let alone the kind of differentiation D offers between mutable/immutable/const/etc variables, so I'm still trying to work out just when to use each - What's different between these two examples, practically speaking? When would you use one over the other?
>
> struct thing1{
>      const int x, y;
> }
>
> struct thing2{
>      int x, y;
> }
>
> Thanks!

You'll be much happier if you don't make the members of a struct const or immutable. When they're const or immutable, you cannot mutate them, and you cannot mutate the struct as a whole (though other members can still be mutated). Not being able to mutate the const members is presumably what you want, but not being able to mutate the struct as a whole can be very annoying. For instance, if you have

struct S
{
    string foo;
    const int bar;
}

auto s = S("hello", 42);
s.foo = "world";
s.bar = 77; // does not compile
s = S("dlang", 99); // does not compile

Presumably, you don't want bar to be able to change (which is why you made it const), so the first error is fine, but the second could be a big problem. By making a portion of the struct const, you can't assign to it anymore or do anything that would mutate it as a whole. You can just mutate its mutable members directly. Contrast this with

struct S
{
    string foo;
    int bar;
}

auto s = S("hello", 42);
s.foo = "world";
s.bar = 77; // compiles
s = S("dlang", 99); // compiles

const t = S("str", 12);
t.foo = "ing"; // does not compile
t.bar = 7; // does not compile
t = S("duck", 2); // does not compile

This version of S can still be const if you want it to be, but it doesn't have to be - though obviously, bar can now be mutated if the struct as a whole is not const. The way to fix that is to provide a getter but not a setter. eg.

struct S
{
public:
    @property string foo() const { return _foo; }
    @property void foo(string value) { _foo = value; }

    @property int bar() const { return _bar; }

private:
    string _foo;
    int _bar;
}

auto s = S("hello", 42);
s.foo = "world";
s.bar = 77; // does not compile
s = S("dlang", 99); // compiles

const t = S("str", 12);
t.foo = "ing"; // does not compile
t.bar = 7; // does not compile
t = S("duck", 2); // does not compile

Because foo provides both a getter and a setter, it can be mutated as before, but because bar only provides a setter, it can't be mutated even when the struct is mutable - but you can still replace its value when you assign a value to the entire struct. And of course, if an instance of the struct is marked as const, then you can't mutate any of it. So, this approach gives you full flexibility.

Now, having const or immutable members for classes isn't generally a problem, beacause they're on the heap, and you don't normally assign a new value to a class (rather, you just assign a new value to a reference to that object so that the reference refers to a different object, but the previous object wasn't actually mutated). e.g.

class C
{
    this(string f, int b)
    {
        foo = f;
        bar = b;
    }

    string foo;
    const int bar;
}

auto c = new C("hello", 42);
c.foo = "world";
c.bar = 77; // does not compile
c = new C("dlang", 99); // compiles

const d = new C("str", 12);
d.foo = "ing"; // does not compile
d.bar = 7; // does not compile
d = new C("duck", 2); // does not compile

So, having const members for classes usually works well, but because structs normally live on the stack rather than having that layer of indirection, giving them const members does tend to get in the way.

- Jonathan M Davis