`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