www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why can't function expecting immutable arg take mutable input?

reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Hello. I still haven't wrapped my mind around the const/immutable thing yet 
and am still stuck in C/C++ mode. :-(

A function that takes mutable arguments cannot be called with immutable 
input at the call site since it does not promise to *not* mutate the input. 
That's of course clear.

Why can't a function that takes an immutable argument be called with a 
mutable input at the call site?

IOW, why isn't mutable implicitly convertible to immutable?

I just finished writing a string processing module which calls multiple 
subroutines, and all of them carrying arguments with type `string` viz. 
`immutable(char)[]` IIUC, and I tried to pass it something which came from 
File.byLine(), then got the error:

function textattr.applyTextAttr (string text) is not callable using argument 
types (char[])

I understand that const can refer to either mutable or immutable, so does 
this mean I should replace all occurrences of `string` in arguments and 
return values of functions by `const(char)[]`?

--
Oct 16 2015
next sibling parent Daniel Kozak <kozzi dlang.cz> writes:
Shriramana Sharma p=C3=AD=C5=A1e v P=C3=A1 16. 10. 2015 v 16:05 +0530:

 Hello. I still haven't wrapped my mind around the const/immutable
 thing yet=20
 and am still stuck in C/C++ mode. :-(
=20
 A function that takes mutable arguments cannot be called with
 immutable=20
 input at the call site since it does not promise to *not* mutate the
 input.=20
 That's of course clear.
=20
 Why can't a function that takes an immutable argument be called with
 a=20
 mutable input at the call site?
=20
 IOW, why isn't mutable implicitly convertible to immutable?
=20
 I just finished writing a string processing module which calls
 multiple=20
 subroutines, and all of them carrying arguments with type `string`
 viz.=20
 `immutable(char)[]` IIUC, and I tried to pass it something which came
 from=20
 File.byLine(), then got the error:
=20
 function textattr.applyTextAttr (string text) is not callable using
 argument=20
 types (char[])
=20


Because immutable means it could resist in ROM so there could be some
optimalization. Const on the other hand is what you are looking for.


 I understand that const can refer to either mutable or immutable, so
 does=20
 this mean I should replace all occurrences of `string` in arguments
 and=20
 return values of functions by `const(char)[]`?
=20


Yes you could, but be carefull that you do not store result
from=C2=A0File.byLine() without dup or idup, because with next calling of
File.byLine() it will probably modificate the previous result.
Oct 16 2015
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 16 October 2015 at 10:35:23 UTC, Shriramana Sharma 
wrote:

 Hello. I still haven't wrapped my mind around the 
 const/immutable thing yet and am still stuck in C/C++ mode. :-(

 A function that takes mutable arguments cannot be called with 
 immutable input at the call site since it does not promise to 
 *not* mutate the input. That's of course clear.

 Why can't a function that takes an immutable argument be called 
 with a mutable input at the call site?


The contract of immutable is such that any reference to immutable 
data is a guarantee that no reference to the same data will 
modify it anywhere in the program. Passing mutable data to a 
function where an immutable parameter is declared would break 
that contract, since the data could be modified through the 
original reference. The compiler can take advantage of such a 
strict contract to make optimizations it would otherwise be 
unable to.

const only guarantees const data will not be modifed through a 
single reference, but says nothing about other references to the 
same data. A const parameter can accept const, immutable, and 
mutable arguments.
Oct 16 2015
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Friday, 16 October 2015 at 10:35:23 UTC, Shriramana Sharma 
wrote:

 I understand that const can refer to either mutable or 
 immutable, so does this mean I should replace all occurrences 
 of `string` in arguments and return values of functions by 
 `const(char)[]`?


Use `inout` attribute for that: take inout(char)[] parameter and 
return inout(char)[] result.
Oct 16 2015
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Friday, 16 October 2015 at 10:35:23 UTC, Shriramana Sharma 
wrote:

 Hello. I still haven't wrapped my mind around the 
 const/immutable thing yet and am still stuck in C/C++ mode. :-(

 A function that takes mutable arguments cannot be called with 
 immutable input at the call site since it does not promise to 
 *not* mutate the input. That's of course clear.

 Why can't a function that takes an immutable argument be called 
 with a mutable input at the call site?

 IOW, why isn't mutable implicitly convertible to immutable?

 I just finished writing a string processing module which calls 
 multiple subroutines, and all of them carrying arguments with 
 type `string` viz. `immutable(char)[]` IIUC, and I tried to 
 pass it something which came from File.byLine(), then got the 
 error:

 function textattr.applyTextAttr (string text) is not callable 
 using argument types (char[])

 I understand that const can refer to either mutable or 
 immutable, so does this mean I should replace all occurrences 
 of `string` in arguments and return values of functions by 
 `const(char)[]`?


This actually *is* possible, if the type you're passing is a 
value type with no indirections. Then you can just pass it by 
value and it will be implicitly convertible to immutable. This 
doesn't work for char because it has indirections (a pointer to 
its data).
Oct 16 2015
parent Meta <jared771 gmail.com> writes:
On Friday, 16 October 2015 at 12:48:42 UTC, Meta wrote:

 This doesn't work for char because it has indirections (a 
 pointer to its data).


Whoops, should be char[], not char.
Oct 16 2015
prev sibling next sibling parent anonymous <anonymous example.com> writes:
On Friday, October 16, 2015 12:35 PM, Shriramana Sharma wrote:


 Why can't a function that takes an immutable argument be called with a
 mutable input at the call site?
 
 IOW, why isn't mutable implicitly convertible to immutable?


immutable says that the data won't ever change. If references to mutable 
data would be implicitly convertible to immutable, then you could break the 
immutable guarantee by mutating through the mutable reference which would 
also be visible through the immutable reference.

Keep in mind that functions/methods may store references and reuse them on 
subsequent calls. If the parameter is immutable, then the function can 
assume that the data doesn't change in between calls. If you could pass 
mutable data, then you could change it between calls, and the function's 
immutability expectation would fail.

Also, multiple threads may work concurrently on the same data. But if you 
could have an immutable reference in one thread and a mutable one in 
another, then "immutable" data could change while the function runs.

An immutable parameter is as much a demand by the function from the caller 
as it is a guarantee to the caller. If you don't need the demand part, and 
only want to guarantee that the function does not alter the argument 
(through that reference), const does that.


 I just finished writing a string processing module which calls multiple
 subroutines, and all of them carrying arguments with type `string` viz.
 `immutable(char)[]` IIUC, and I tried to pass it something which came from
 File.byLine(), then got the error:
 
 function textattr.applyTextAttr (string text) is not callable using
 argument types (char[])
 
 I understand that const can refer to either mutable or immutable, so does
 this mean I should replace all occurrences of `string` in arguments and
 return values of functions by `const(char)[]`?


If the functions don't actually require immutable data, then yes, use const 
instead.
Oct 16 2015
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Fri, Oct 16, 2015 at 04:05:19PM +0530, Shriramana Sharma via
Digitalmars-d-learn wrote:

 Hello. I still haven't wrapped my mind around the const/immutable
 thing yet and am still stuck in C/C++ mode. :-(
 
 A function that takes mutable arguments cannot be called with
 immutable input at the call site since it does not promise to *not*
 mutate the input.  That's of course clear.
 
 Why can't a function that takes an immutable argument be called with a
 mutable input at the call site?


What you want here is const, not immutable.

Const is a guarantee that the argument will not be modified *by the
function*. Immutable, however, is a much stronger guarantee: that the
argument will not be modified by *anyone*. That is, the compiler is free
to assume that the result of calling a pure function that takes
immutable arguments will never ever change, no matter what, so it's safe
to elide all but the first call to that function and cache its result.
You can't do this with const, because it's possible that somebody may
hold a mutable reference to the data and mutate it between calls.


[...]

 I understand that const can refer to either mutable or immutable, so
 does this mean I should replace all occurrences of `string` in
 arguments and return values of functions by `const(char)[]`?


[...]

If your functions don't need the stronger guarantee of immutable, yes,
use const(char)[] instead. It's what const was designed for -- to take
arguments that can be either mutable or immutable.


T

-- 
Tech-savvy: euphemism for nerdy.
Oct 16 2015
parent Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
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?

--
Oct 16 2015
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/16/2015 03:35 AM, Shriramana Sharma wrote:

 Hello. I still haven't wrapped my mind around the const/immutable thing yet
 and am still stuck in C/C++ mode. :-(


Welcome to the club! :) You can read my understanding of the issue at 
the following link:

 
http://ddili.org/ders/d.en/const_and_immutable.html#ix_const_and_immutable.parameter,%20const%20vs.%20immutable

Ali
Oct 16 2015
parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
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...

--
Oct 16 2015
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Oct 16 2015
parent Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
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...

--
Oct 16 2015
prev sibling parent Jakob Ovrum <jakobovrum gmail.com> writes:
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_
mmutable.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.
Oct 16 2015