On 11/8/11 1:45 PM, deadalnix wrote:
> Le 08/11/2011 20:33, Andrei Alexandrescu a écrit :
>> On 11/8/11 10:42 AM, 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.
>>
>> If it makes you feel better, this was on the table. We settled for
>> inout. It's water under the bridge. Let's not waste time on this.
>>
>> Andrei
>
> You should definitively communicate more on that.

There was discussion about it. That is a very old decision - it was made years before you joined this newsgroup.

> Especially, what are
> the points that made inout the « winning » solution ?

We felt it sits better. That particular subjective decision can be questioned, but there is little point to it right now.


Andrei

On 11/8/2011 11:10 AM, Martin Nowak wrote:
> I personally find it much more astonishing that inout methods finally work.

In retrospect, it seems like a fairly straightforward solution, but it took us many, many hours and gallons of coffee. And, as far as I know, this solution has not been seen before in any other language, though there is a crying need for it in C++.

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.

On Tue, Nov 8, 2011 at 4:20 PM, 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.
>

I've always thought "defenestrate" should have been used as a keyword instead of the more general "throw".

The problem is, that by adding a new keyword we could accidentally
invalidate lots of identifiers.
Everything else is true, i agree :-)

On Wed, Nov 9, 2011 at 3:20 AM, 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.
>

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.

On the other handpaw, D2 has done a bit of mess with some of its tags name choice, it has "@safe" and "pure", but this choice looks arbitrary, why it isn't "safe" and "@pure"?

Bye,
bearophile

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.

>
> In retrospect, it seems like a fairly straightforward solution, but it took us many, many hours and gallons of coffee. And, as far as I know, this solution has not been seen before in any other language, though there is a crying need for it in C++.

Yeah, the two common C++ solutions are either overload macros or non-transitive const.
Remarkably enough it's hardly understood in a C++ context that transitive
qualifiers offer much stronger guarantees.
Take shared_ptr as a prominent example for the disaster.

      _Tp*
      get() const // never throws
      { return _M_ptr; }

With the even worse C++ solution to this being const_iterator.

On 11/8/2011 3:57 PM, bearophile wrote:
> On the other handpaw, D2 has done a bit of mess with some of its tags name
> choice, it has "@safe" and "pure", but this choice looks arbitrary, why it
> isn't "safe" and "@pure"?

Because of pure came first and @safe came much, much later.

On 11/8/2011 3:57 PM, Martin Nowak wrote:
> Yeah, the two common C++ solutions are either overload macros or non-transitive
> const.
> Remarkably enough it's hardly understood in a C++ context that transitive
> qualifiers offer much stronger guarantees.
> Take shared_ptr as a prominent example for the disaster.
>
> _Tp*
> get() const // never throws
> { return _M_ptr; }
>
> With the even worse C++ solution to this being const_iterator.

Many top shelf C++ programmers do understand these issues. They've complained to me about the unattractiveness of the various C++ solutions to the inout problem.

D's solution seems obvious only in retrospect.

On 11/08/2011 08:10 PM, Martin Nowak wrote:
> On Tue, 08 Nov 2011 02:08:27 +0100, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> http://drdobbs.com/blogs/cpp/231902461
>>
>> Anyone want to do the reddit honors?
>
> I personally find it much more astonishing that inout methods finally work.
>
> All of this with one method definition, without const_cast macros,
> without overload ambiguities
> but with transitive qualifier safety.
>

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.