> Well use of auto can be ambiguous here I think.

I'm not sure, frankly. We should consult with Walter and co. because they have a better idea about syntax readability.

> What about auto const ref ?

That will force you to have both auto const and auto ref at the same time.

On Tue, Nov 8, 2011 at 5:48 PM, deadalnix <deadalnix@gmail.com> wrote:
> Le 08/11/2011 14:36, Gor Gyolchanyan a écrit :
>>
>> I agree with _inout_ being a bad choice.
>> I'd rather use something involving _auto_, because this kind of use of
>> _auto_ is already employed in _auto ref_ parameters and is visually
>> unambiguous.
>> Probably _auto const_ would do the trick.
>>
>> The actual _inout_ keyword could be flagged as deprecated and removed during the next breaking change in D (along with all other wonderful breaking changes that were proposed).
>>
>
> Well use of auto can be ambiguous here I think.
>
> What about auto const ref ?
>

Gor Gyolchanyan:

> I agree with _inout_ being a bad choice.
> I'd rather use something involving _auto_, because this kind of use of
> _auto_ is already employed in _auto ref_ parameters and is visually
> unambiguous.

I rather hate a tag name that contains a space in the middle like "auto ref". I like "auto_ref" much better.

Bye,
bearophile

Makes sense, but it looks ugly. I don't know about others, but for me
underscores in names are associated with things, that you shouldn't
touch (including private data and functions).
Uppercase, on the other hand is associated with high-level constructs
(which are usually in user-space only).
This leads to the conclusion, that keywords should be short lowercase
one-word identifiers.

To resolve the accurately noticed "ugly space" we could require parenthesis. const, shared and immutable use parentheses and it looks very elegant.

auto(const) and auto(ref) looks better, then auto const and auto ref, IMO.

On Tue, Nov 8, 2011 at 6:05 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Gor Gyolchanyan:
>
>> I agree with _inout_ being a bad choice.
>> I'd rather use something involving _auto_, because this kind of use of
>> _auto_ is already employed in _auto ref_ parameters and is visually
>> unambiguous.
>
> I rather hate a tag name that contains a space in the middle like "auto ref". I like "auto_ref" much better.
>
> Bye,
> bearophile
>

On Tue, 08 Nov 2011 15:08:19 +0200, deadalnix <deadalnix@gmail.com> wrote:

> Le 08/11/2011 02:08, Walter Bright a écrit :
>> http://drdobbs.com/blogs/cpp/231902461
>>
>> Anyone want to do the reddit honors?
>
> Great article. The only point I would raise is the choice of inout as a keyword for this.
>
> This make no sens whatsoever. Here is why :
> - inout did exist in D1 and is different.
> - in and out qualifier already exists and have nothing to do with inout.
> - in and out are used for contracts and have nothing to do with inout.
> - the inout term has nothing to do with const/immutable/mutable. This is in a totally different lexical field.
>
> Another keyword should be choosen. vconst, as suggested here : http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2 is way more appropriate.
>
> On external details, but still important, I face the need of inout few days ago and did knew about it. The documentation on const/immutable ( http://www.d-programming-language.org/const3.html ) doesn't mention it. The page on fucntion mention it, but it would be nice to have at least a link on the const/immutable page.

auto fun(return(type) a, ...)
return(T) fun(return(S) a, ...)

Le 08/11/2011 15:16, Gor Gyolchanyan a écrit :
> Makes sense, but it looks ugly. I don't know about others, but for me
> underscores in names are associated with things, that you shouldn't
> touch (including private data and functions).
> Uppercase, on the other hand is associated with high-level constructs
> (which are usually in user-space only).
> This leads to the conclusion, that keywords should be short lowercase
> one-word identifiers.
>

Agreed.

> To resolve the accurately noticed "ugly space" we could require
> parenthesis. const, shared and immutable use parentheses and it looks
> very elegant.
>
> auto(const) and auto(ref) looks better, then auto const and auto ref, IMO.
>

Parenthesis are painful to write on some keyboard. We should use them only to desembiguate when appropriate, not as a main syntax. This is why I advocate for this construct having its own keyword.

On Tue, 08 Nov 2011 16:39:35 +0200, so <so@so.so> wrote:

> auto fun(return(type) a, ...)
> return(T) fun(return(S) a, ...)

Damn, nobody likes it, and i was expecting at least a nobel prize on math.

Unless you write a template constraint, this will force you to use the same type, instead of the same storage class.

On Tue, Nov 8, 2011 at 8:42 PM, so <so@so.so> wrote:
> On Tue, 08 Nov 2011 16:39:35 +0200, so <so@so.so> wrote:
>
>> auto fun(return(type) a, ...)
>> return(T) fun(return(S) a, ...)
>
> Damn, nobody likes it, and i was expecting at least a nobel prize on math.
>

On Tue, 08 Nov 2011 18:56:59 +0200, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:

> Unless you write a template constraint, this will force you to use the
> same type, instead of the same storage class.
>
> On Tue, Nov 8, 2011 at 8:42 PM, so <so@so.so> wrote:
>> On Tue, 08 Nov 2011 16:39:35 +0200, so <so@so.so> wrote:
>>
>>> auto fun(return(type) a, ...)
>>> return(T) fun(return(S) a, ...)
>>
>> Damn, nobody likes it, and i was expecting at least a nobel prize on math.
>>

return(T) fun(return(S) a, ...)

Functions just like inout right now, and with:

auto fun(return(type) a, ...)

I meant to suggest if not said otherwise (as in the case above) we can just go return what it was passed.
(I am not sure, probably inout already does this too)

Le 08/11/2011 18:02, so a écrit :
> On Tue, 08 Nov 2011 18:56:59 +0200, Gor Gyolchanyan
> <gor.f.gyolchanyan@gmail.com> wrote:
>
>> Unless you write a template constraint, this will force you to use the
>> same type, instead of the same storage class.
>>
>> On Tue, Nov 8, 2011 at 8:42 PM, so <so@so.so> wrote:
>>> On Tue, 08 Nov 2011 16:39:35 +0200, so <so@so.so> wrote:
>>>
>>>> auto fun(return(type) a, ...)
>>>> return(T) fun(return(S) a, ...)
>>>
>>> Damn, nobody likes it, and i was expecting at least a nobel prize on
>>> math.
>>>
>
> return(T) fun(return(S) a, ...)
>
> Functions just like inout right now, and with:
>
> auto fun(return(type) a, ...)
>
> I meant to suggest if not said otherwise (as in the case above) we can
> just go return what it was passed.
> (I am not sure, probably inout already does this too)

You'll face a problem when it come to define variable within the function and not in its definition.

I'm affraid this will become very confusing in this case.

On Tue, 08 Nov 2011 19:09:40 +0200, deadalnix <deadalnix@gmail.com> wrote:

> You'll face a problem when it come to define variable within the function and not in its definition.
>
> I'm affraid this will become very confusing in this case.

inout fun(inout) {
   inout var; // This is what you are saying i believe.
   ....
}

You are definitely right, if this use case was intended.