When is there a noticable difference when using const values instead of immutable values in a function body? And when should immutable be used instead of const?

f(){
  const x = g();
  immutable y = g();
  ... do stuff with x and y …
}

I'm comparing D to C++ and I get the following mapping:

D:
enum constant = number

C++:
enum : decltype(number) { constant = number }

D:
auto p =  g()

C++:
auto p = g()

D:
const p = g()

C++:
const auto p = g()

D:
immutable p = g()

C++:
hmmm...

Has anyone done a feature by feature comparison with C++? It would be interesting to see what it looks like.

Also, in file scope, would C++:

constexpr auto constant = 3;

be the same as:

immutable constant = 3;

?

On Wednesday, 4 December 2019 at 14:44:43 UTC, Ola Fosheim Grøstad wrote:
> When is there a noticable difference when using const values instead of immutable values in a function body? And when should immutable be used instead of const?
>
> f(){
>   const x = g();
>   immutable y = g();
>   ... do stuff with x and y …
> }
>
> I'm comparing D to C++ and I get the following mapping:
>
> D:
> enum constant = number
>
> C++:
> enum : decltype(number) { constant = number }
>
> D:
> auto p =  g()
>
> C++:
> auto p = g()
>
> D:
> const p = g()
>
> C++:
> const auto p = g()
>
> D:
> immutable p = g()
>
> C++:
> hmmm...
>
> Has anyone done a feature by feature comparison with C++? It would be interesting to see what it looks like.

Unfortunately I am not yet good with D to answer your question .
But Ali Çehreli made some comparesions with C++.
https://dconf.org/2013/talks/cehreli.pdf
And I think you will find the answers of your questions in it also.

On Wednesday, 4 December 2019 at 14:44:43 UTC, Ola Fosheim Grøstad wrote:
> When is there a noticable difference when using const values instead of immutable values in a function body? And when should immutable be used instead of const?
>
> f(){
>   const x = g();
>   immutable y = g();
>   ... do stuff with x and y …
> }

There is a difference I guess if g() returns a reference type and is an inout function. immutable y will only work if the reference returned is immutable.

Const is a promise to the rest of the code that you will never mutate it. Immutable is a promise by the rest of the code that it will never mutate.

Immutable is more powerful, allowing data sharing in overlapping slices and between threads without locks. Const is more versatile, allowing references to data regardless of its mutability.

So if g() always returns immutable, it’s best to receive it as such, not const. If it can be either, it must be received as const.

> I'm comparing D to C++ and I get the following mapping:

Does that make sense at all? D’s const is transitive, C++’s is not.

Bastiaan.

On Wednesday, 4 December 2019 at 22:29:13 UTC, kerdemdemir wrote:
> Unfortunately I am not yet good with D to answer your question .
> But Ali Çehreli made some comparesions with C++.
> https://dconf.org/2013/talks/cehreli.pdf
> And I think you will find the answers of your questions in it also.

Thanks. He didn't really compare to modern C++, but I appreciate the pointer.

Seems to me that immutable references are primarily useful when calling a function with two references to an array. So you can be certain that the read-only reference will not be modified within the function (if both parameters point to the same array as they can with a const reference).

Also, constexpr in C++ is a CTFE constraint and not a type, so not fully comparable to immutable, but same effect... perhaps. Not sure how smart compilers are in this regard.

So immutable references i D is basically the same as const-references with restrict in C/C++ (non-standard, but common C++)?

On Wednesday, 4 December 2019 at 22:43:35 UTC, Bastiaan Veelo wrote:
> There is a difference I guess if g() returns a reference type and is an inout function. immutable y will only work if the reference returned is immutable.

But not for values?

> Const is a promise to the rest of the code that you will never mutate it. Immutable is a promise by the rest of the code that it will never mutate.

But if it isn't marked as "shared" then only the current thread will modify it, so it is only different if you have a mutable reference as well that could modify the same object as a const reference.

> So if g() always returns immutable, it’s best to receive it as such, not const. If it can be either, it must be received as const.

Is there a way to specify in generic code that you want the best fit of a const/immutable reference depending on the return type (but not a mutable one)?


>> I'm comparing D to C++ and I get the following mapping:
>
> Does that make sense at all? D’s const is transitive, C++’s is not.

Yes, but it is the same for value types.

On Wednesday, 4 December 2019 at 22:51:01 UTC, Ola Fosheim Grøstad wrote:
> Is there a way to specify in generic code that you want the best fit of a const/immutable reference depending on the return type (but not a mutable one)?

I mean, if f() return mutable or const then it should be const, but if it returns immutable then it should be immutable. Something like:

readonly myref = f()

On 12/4/19 5:57 PM, Ola Fosheim Grøstad wrote:
> On Wednesday, 4 December 2019 at 22:51:01 UTC, Ola Fosheim Grøstad wrote:
>> Is there a way to specify in generic code that you want the best fit of a const/immutable reference depending on the return type (but not a mutable one)?
> 
> I mean, if f() return mutable or const then it should be const, but if it returns immutable then it should be immutable. Something like:
> 
> readonly myref = f()
> 
> 
void foo(alias f)()
{
   alias ConstType = const(typeof(f()));
   pragma(msg, ConstType);
}

    const(int) a() { return 1; }
immutable(int) b() { return 1; }
          int  c() { return 1; }

void main()
{
    foo!a(); // const(int)
    foo!b(); // immutable(int)
    foo!c(); // const(int)
}

-Steve

On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven Schveighoffer wrote:
> void main()
> {
>     foo!a(); // const(int)
>     foo!b(); // immutable(int)
>     foo!c(); // const(int)
> }

Ok, so one has to use a wrapper and then "catch" the result with auto?

auto x = foo!f();

On Thursday, 5 December 2019 at 00:05:26 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven Schveighoffer wrote:
>> void main()
>> {
>>     foo!a(); // const(int)
>>     foo!b(); // immutable(int)
>>     foo!c(); // const(int)
>> }
>
> Ok, so one has to use a wrapper and then "catch" the result with auto?
>
> auto x = foo!f();

Nevermind...