On Wed, 09 Nov 2011 01:20:44 +0200, Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/8/2011 9:37 AM, Gor Gyolchanyan wrote:
>> Polluting keyword space is not a good idea unless it's impossible to
>> interfere with identifiers.
>> If keywords used a special syntax, like starting with a special
>> character, then this wouldn't be an issue
>
>
> The whole "too many keywords" issue strikes me as strange. English has over a million words in it. Who cares if a language uses 80 or 100 of them? What difference can it possibly make? How can an extra 20 words pollute the million word namespace (and not including any non-word identifiers (like inout))?
>
> Another silly aspect of this issue is all keywords could be replaced by a sequence of special characters. For example, we could replace inout with ##. Voila! Less keywords! But is that better?
>
> Keywords exist to make the language more readable. That's why we use inout instead of ##, and it's why we use + instead of add.
>
> D is a rich language. That means it's going to have more syntax, more keywords and more symbols.

My only concern with keywords is that to me a keyword must lift its own weight,
For specific issues such as this, if there is a library solution (which i think is not applicable here),
or a solution which requires an overload to an already defined keyword, it would be IMO a better choice.
I can see why we have a keyword for it, and why it is not @inout. I suggested "return" because it semantically fits the definition of inout.
Yet, you are again right, i didn't think about neither local/variable usage nor tuple syntax.

On Tue, 08 Nov 2011 03:16:30 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 11/08/2011 02:08 AM, Walter Bright wrote:
>> http://drdobbs.com/blogs/cpp/231902461
>>
>> Anyone want to do the reddit honors?
>
> Nice article!
>
>
>  > It isn't a template, and inout can only be used on function parameters and the return value.
>
> What about local variables?

Yes.  Local variables cease to exist beyond the scope of the function, so they are allowed.  the main principal of inout is that it only exists as inout during the scope of the function, then goes back to its original const flavor (const/immutable/mutable).  In fact, my original proposal called inout "scoped const".

-Steve

On Tue, 08 Nov 2011 18:57:19 -0500, Martin Nowak <dawg@dawgfoto.de> wrote:

> On Wed, 09 Nov 2011 00:01:09 +0100, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 11/8/2011 11:10 AM, Martin Nowak wrote:
>>> I personally find it much more astonishing that inout methods finally work.
> I literally meant methods as in member functions.
> Being able to use inout as method qualifier is way more
> important than achieving the same for free functions as it
> makes transitive qualifiers almost hassle free in simple cases.

To give a bit of trivia, the main motivator for proposing what is now inout was trying to port Tango to D2.  In doing this, I realized that in order to be const-correct, I was going to have to triplicate all property accessors on classes (and Tango uses classes + properties much more than Phobos does).  The prospect of having three *identical* copies of the same function just so I could have something as simple as an accessor was reason enough to find a better solution before moving forward on Tango for D2.

In other words, the astonishment was intentional :)

BTW, I want to publicly thank Kenji Hara for his work on making inout a reality.  He created the patch that solved all the remaining inout problems, then quickly fixed most of the remaining bugs found with his patch before this last release.  Without his work, inout would still be a pipe-dream!

-Steve

On Tue, 08 Nov 2011 08:08:19 -0500, 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.

The argument given to use inout is that it was a dead keyword (it's totally superseded by ref).

At the time of proposal, an argument against such a feature was that people didn't want to add any more keywords.  Reusing inout keyword was a way to cut the legs off that argument, although I would have preferred not to use inout.

It is kind of related, as in, the qualifier you pass in becomes the qualifier passed out.

>
> 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.

That documentation is not exactly documentation.  It's an article on const.  I agree it needs to be updated.

-Steve

On 09.11.2011 00:57, bearophile wrote:
> Walter:
>
>> The whole "too many keywords" issue strikes me as strange. English has over a
>> million words in it. Who cares if a language uses 80 or 100 of them? What
>> difference can it possibly make? How can an extra 20 words pollute the million
>> word namespace (and not including any non-word identifiers (like inout))?
>
> I agree. This is also why I have suggested "auto_ref" instead of "auto ref", that I think is a bit confusing.

"auto ref" is something we should *really* get rid of. Because it isn't 'auto'.

There should be a symmetry between:

auto     --- const
auto ref --- const ref

But there isn't. The correct patten is:

auto     --- const
ref      --- const ref
auto ref --- const auto ref

And note that auto const ref is not the same as const auto ref.

I'd be happy with auto_ref or autoref or pretty much any sequence of characters that doesn't contain " auto ".

Timon Gehr Wrote:

> Actually, we don't have the transitive qualifier safety yet:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=6912
> 
> But it should be a fairly easy fix to do.

Yeah, I think a simple fix will be enough here.

Don Wrote:

> I'd be happy with auto_ref or autoref or pretty much any sequence of characters that doesn't contain " auto ".

As it's a function attribute, it doesn't have to be a keyword in the first place. @autoref is just fine.

> The whole "too many keywords" issue strikes me as strange. English has
> over a million words in it. Who cares if a language uses 80 or 100 of
> them? What difference can it possibly make? How can an extra 20 words
> pollute the million word namespace (and not including any non-word
> identifiers (like inout))?
>
> Another silly aspect of this issue is all keywords could be replaced by
> a sequence of special characters. For example, we could replace inout
> with ##. Voila! Less keywords! But is that better?
>
> Keywords exist to make the language more readable. That's why we use
> inout instead of ##, and it's why we use + instead of add.

Well, using inout contradict this argument. inout isn't reminding in any way of its functionnality. It is more readable than ##, for sure, but way less than any word from const/immutable lexical field.

On 09/11/2011 15:29, deadalnix wrote:
> inout isn't reminding in any way of its functionnality. It is more
> readable than ##, for sure, but way less than any word from
> const/immutable lexical field.

inout means transfer the input qualifier to the output, it is descriptive enough.

On 11/9/11 9:58 AM, Nick Treleaven wrote:
> On 09/11/2011 15:29, deadalnix wrote:
>> inout isn't reminding in any way of its functionnality. It is more
>> readable than ##, for sure, but way less than any word from
>> const/immutable lexical field.
>
> inout means transfer the input qualifier to the output, it is
> descriptive enough.

Thank you. I was itching to write that but was hoping somebody else would.

Andrei