`return const` parameters make `inout` obsolete

Zach the Mystic via Digitalmars-d digitalmars-d at puremagic.com
Mon Mar 16 08:54:19 PDT 2015

On Monday, 16 March 2015 at 15:39:39 UTC, ketmar wrote:
> On Mon, 16 Mar 2015 15:33:40 +0000, Zach the Mystic wrote:
>> On Monday, 16 March 2015 at 14:23:42 UTC, ketmar wrote:
>>> On Mon, 16 Mar 2015 14:17:57 +0000, Zach the Mystic wrote:
>>>> char* fun(return const char* x);
>>>> Compiler has enough information to adjust the return type of 
>>>> `fun()`
>>>> to that of input `x`. This assumes return parameters have 
>>>> been
>>>> generalized to all reference types. Destroy.
>>> but why compiler has to rewrite return type? i never told it 
>>> to do
>>> that!
>> It has to if you pass an immutable to x, which you're allowed 
>> to do. It
>> only gives an error if you assign the result to a mutable 
>> variable. The
>> point is that the signature still contains all the information 
>> it needs
>> without `inout`. What old errors will fail to be reported and 
>> what new
>> errors would it cause? I haven't been able to think of any.
> this is the question of consistency. if i wrote `char* fun()`, 
> i want fun
> to return `char*`, and i'm not expecting it to change in a 
> slightest. i
> don't like when compiler starts to change things on it's own.

I think it's just less cluttered than `inout`. The simple fact is 
that if you try to assign an immutable variable to a mutable 
reference, you will still get an error. I doubt it would take 
long for programmers to adjust to the new way of reading the 
signatures. They just see `return` sitting there in front of 
`const` and know how to handle the situation.

More information about the Digitalmars-d mailing list