On 10/16/2015 07:02 PM, Shriramana Sharma wrote:

> your book which provides

I am glad that it is useful. :)

> My question was however to the root of the issue, as to *why* the compiler
> cannot consider mutable as immutable just like in C/C++ any non-const can be
> taken as const.

Actually, others gave the answer to that question, which was apparently not very clear. :)

In the context of your question, immutable is a requirement of the function from its user. It is a demand that the argument shall not mutate. That's why mutable cannot be considered as mutable.

For example, if you write a File struct and take the file name as string, you don't need to make a copy of the file name because you know that it will not mutate as long as your File object is alive. (You can cast immutable away with undefined consequences but it's a different issue. :) )

> It would seem that the answer is one related to optimization. Obviously,
> labeling an argument as immutable can be done only if we are sure that we
> will have to process only immutable input, thereby paving the opportunity
> for the compiler to optimize some memory access or allocation or such – I'm
> not much clear beyond that but that's enough for me now...

That and what I said above: the user can rely on this guarantee as well.

Ali

On Saturday, 17 October 2015 at 02:03:01 UTC, Shriramana Sharma wrote:
> Ali Çehreli wrote:
>
> http://ddili.org/ders/d.en/const_and_immutable.html#ix_const_and_immutable.parameter, %20const%20vs.%20immutable
>
> Hi Ali – I take this chance to personally thank you sincerely for your book which provides much-needed hand-holding in my baby D-steps. I did read that chapter already and IMO you have given clear instructions as to when to use const and when immutable.
>
> My question was however to the root of the issue, as to *why* the compiler cannot consider mutable as immutable just like in C/C++ any non-const can be taken as const.
>
> It would seem that the answer is one related to optimization. Obviously, labeling an argument as immutable can be done only if we are sure that we will have to process only immutable input, thereby paving the opportunity for the compiler to optimize some memory access or allocation or such – I'm not much clear beyond that but that's enough for me now...

It appears that the linked chapter doesn't explain *why* you would want to receive immutable arguments.

In my experience, the most common motivation is a desire to escape a reference to the argument. We want to read the data later, but when we do, we want it to be unchanged from when we received it:

---
struct S
{
    immutable(int)[] numbers;

    this(immutable(int)[] numbers)
    {
        this.numbers = numbers;
    }

    void printNumbers()
    {
        import std.stdio;
        writeln(numbers);
    }
}

immutable numbers = [1, 2, 3];
auto s = S(numbers);
/* ... */
s.printNumers(); // [1, 2, 3]
---

In the above code, *no matter what code is run between construction and `printNumbers`*, it will always print the same numbers it received at construction, as the numbers are immutable. Because of this guarantee, S.numbers can simply alias the constructor argument as seen in the constructor body, instead of say, copying the numbers into a new heap-allocated copy of the array. If we used const instead of immutable, there would be no such guarantee, as const can refer to mutable data: the numbers could have been overwritten between construction and the call to `printNumbers`.

Another common use of immutable is to share data between multiple threads. As immutable data never changes after initialization, it can be passed between threads and read freely without worrying about data races.

const in D simply exists to bridge mutable and immutable data. It is different from C++'s const, despite sharing the same name.

Thanks all, for your kind explanations.

Would then constString (for const(char)[]) and inoutString (for inout(char)
[]) be useful aliases if included in the runtime?

-- 
Shriramana Sharma, Penguin #395953

Ali Çehreli wrote:

> Actually, others gave the answer to that question, which was apparently not very clear. :)

Yes it was clear and I did understand it: and I posted a reply thanking the others too, but for some reason it was still sitting in my outbox...

-- 
Shriramana Sharma, Penguin #395953