www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Type Qualifiers and Wild Cards

reply Walter Bright <newshound2 digitalmars.com> writes:
http://drdobbs.com/blogs/cpp/231902461

Anyone want to do the reddit honors?
Nov 07 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 http://drdobbs.com/blogs/cpp/231902461

It's a nice explanation, quite simple to understand, despite it lacks some details. Bye, bearophile
Nov 07 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 Nov 2011 20:08:27 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 http://drdobbs.com/blogs/cpp/231902461

 Anyone want to do the reddit honors?

http://www.reddit.com/r/programming/comments/m497s/type_qualifiers_and_wild_cards_in_the_d/ -Steve
Nov 07 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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 

What about local variables?
Nov 08 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/8/2011 12:16 AM, Timon Gehr wrote:
 Nice article!

Thanks!
  > It isn't a template, and inout can only be used on function parameters and
 the return value.

 What about local variables?

Just use const for them.
Nov 08 2011
parent reply Don <nospam nospam.com> writes:
On 08.11.2011 09:33, Walter Bright wrote:
 On 11/8/2011 12:16 AM, Timon Gehr wrote:
 Nice article!

Thanks!
 It isn't a template, and inout can only be used on function

the return value. What about local variables?

Just use const for them.

This compiles: inout(int *) foo(inout(int *) a) { inout x = a; return x; } and it doesn't compile if you replace 'inout x' with 'const x'.
Nov 08 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/8/2011 12:44 AM, Don wrote:
 This compiles:

 inout(int *) foo(inout(int *) a)
 {
 inout x = a;
 return x;
 }

 and it doesn't compile if you replace 'inout x' with 'const x'.

inout can implicitly convert to const, but const cannot implicitly convert to inout, hence the error on the return x; But you're right, use inout in the body, and it is treated much like const.
Nov 08 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Nov 09 2011
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
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.
Nov 08 2011
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
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 ?
Nov 08 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 08-11-2011 15:02, Gor Gyolchanyan wrote:
 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.

I know I wouldn't enjoy typing three keywords on a single parameter. :)
 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 ?


- Alex
Nov 08 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
 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 =E9crit :
 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 ?

Nov 08 2011
prev sibling next sibling parent reply so <so so.so> writes:
On Tue, 08 Nov 2011 15:08:19 +0200, deadalnix <deadalnix gmail.com> wrot=
e:

 Le 08/11/2011 02:08, Walter Bright a =C3=A9crit :
 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 =

 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 inou=

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

 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=

 link on the const/immutable page.

auto fun(return(type) a, ...) return(T) fun(return(S) a, ...)
Nov 08 2011
next sibling parent deadalnix <deadalnix gmail.com> writes:
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.
Nov 08 2011
prev sibling next sibling parent RivenTheMage <riven-mage id.ru> writes:
 auto fun(return(type) a, ...)

auto fun(ret a, ...) ?
Nov 08 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/8/2011 6:39 AM, so wrote:
 auto fun(return(type) a, ...)
 return(T) fun(return(S) a, ...)

Thought about using 'return', but it just looked confusing as hell (think about lambdas).
Nov 08 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 08 2011
parent reply deadalnix <deadalnix gmail.com> writes:
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. Especially, what are the points that made inout the « winning » solution ?
Nov 08 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 08 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 08 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Nov 08 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 08 2011
prev sibling parent reply Don <nospam nospam.com> writes:
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 ".
Nov 09 2011
parent Kagamin <spam here.lot> writes:
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.
Nov 09 2011
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
 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.
Nov 09 2011
parent reply Nick Treleaven <nospam example.com> writes:
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.
Nov 09 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 09 2011
parent Tobias Pankrath <tobias pankrath.net> writes:
Andrei Alexandrescu wrote:

 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

it would be a good solution, if in and out didn't exists. I was _very_ confused, when I first saw inout and thougth it would be a combination of in and out. So I think it deserves a prominent place in the documentation next to in and out.
Nov 09 2011
prev sibling next sibling parent so <so so.so> writes:
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.
Nov 08 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.

Nov 08 2011
prev sibling next sibling parent so <so so.so> writes:
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)
Nov 08 2011
prev sibling next sibling parent so <so so.so> writes:
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.
Nov 08 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Actually, I can make it a library solution right now.
Just provide a template, which takes a symbolic representation of
constness and a type and constructs the appropriately const type.
And a template, which extracts the const-ness of a type.
It's gonna look ugly, but it will work.

On Tue, Nov 8, 2011 at 9:02 PM, so <so so.so> wrote:
 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)

Nov 08 2011
prev sibling next sibling parent so <so so.so> writes:
On Tue, 08 Nov 2011 19:21:50 +0200, Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com> wrote:

 Actually, I can make it a library solution right now.
 Just provide a template, which takes a symbolic representation of
 constness and a type and constructs the appropriately const type.
 And a template, which extracts the const-ness of a type.
 It's gonna look ugly, but it will work.

How ugly it can get, it is a keyword of its own, for single purpose! :)
Nov 08 2011
prev sibling next sibling parent so <so so.so> writes:
On Tue, 08 Nov 2011 19:20:49 +0200, RivenTheMage <riven-mage id.ru> wrote:

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

auto fun(ret a, ...) ?

Don't dare take my ret away, unless you give back something that really counts.
Nov 08 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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

On Tue, Nov 8, 2011 at 9:28 PM, so <so so.so> wrote:
 On Tue, 08 Nov 2011 19:21:50 +0200, Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com> wrote:

 Actually, I can make it a library solution right now.
 Just provide a template, which takes a symbolic representation of
 constness and a type and constructs the appropriately const type.
 And a template, which extracts the const-ness of a type.
 It's gonna look ugly, but it will work.

How ugly it can get, it is a keyword of its own, for single purpose! :)

Nov 08 2011
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--f46d04308560958cef04b141bef3
Content-Type: text/plain; charset=ISO-8859-1

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". --f46d04308560958cef04b141bef3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <span style=3D"background-color: transparent; ">On Tue, Nov 8, 2011 at 4:20= PM, Walter Bright </span><span dir=3D"ltr" style=3D"background-color: tran= sparent; ">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 dig= italmars.com</a>&gt;</span><span style=3D"background-color: transparent; ">= wrote:</span><br> <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im= ">On 11/8/2011 9:37 AM, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Polluting keyword space is not a good idea unless it&#39;s impossible to<br=

If keywords used a special syntax, like starting with a special<br> character, then this wouldn&#39;t be an issue<br> </blockquote> <br> <br></div> The whole &quot;too many keywords&quot; issue strikes me as strange. Englis= h 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 poll= ute the million word namespace (and not including any non-word identifiers = (like inout))?<br> <br> Another silly aspect of this issue is all keywords could be replaced by a s= equence of special characters. For example, we could replace inout with ##.= Voila! Less keywords! But is that better?<br> <br> Keywords exist to make the language more readable. That&#39;s why we use in= out instead of ##, and it&#39;s why we use + instead of add.<br> <br> D is a rich language. That means it&#39;s going to have more syntax, more k= eywords and more symbols.<br> </blockquote></div><br><div>I&#39;ve always thought &quot;defenestrate&quot= ; should have been used as a keyword instead of the more general &quot;thro= w&quot;.</div> --f46d04308560958cef04b141bef3--
Nov 08 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.

Nov 08 2011
prev sibling next sibling parent so <so so.so> writes:
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.
Nov 08 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 08 Nov 2011 08:08:19 -0500, deadalnix <deadalnix gmail.com> wrot=
e:

 Le 08/11/2011 02:08, Walter Bright a =C3=A9crit :
 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 =

 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 inou=

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

 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 n= ot = 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=

 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
Nov 09 2011
prev sibling next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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).

On Tue, Nov 8, 2011 at 5:08 PM, deadalnix <deadalnix gmail.com> wrote:
 Le 08/11/2011 02:08, Walter Bright a =E9crit :
 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 =

 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 da=

 ago and did knew about it. The documentation on const/immutable (
 http://www.d-programming-language.org/const3.html ) doesn't mention it. T=

 page on fucntion mention it, but it would be nice to have at least a link=

 the const/immutable page.

Nov 08 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Nov 08 2011
parent deadalnix <deadalnix gmail.com> writes:
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.
Nov 08 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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

Nov 08 2011
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
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. ---- import std.stdio; class C { inout(int) foo() inout { return a; } int a; } void printType(T)(T t) { writeln(typeid(t.foo())); } void main() { auto a = new immutable(C)(); auto b = new C(); printType!(immutable C)(a); printType!(const C)(a); printType!(const C)(b); printType!(C)(b); }
Nov 08 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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++.
Nov 08 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 08 2011
prev sibling parent Kagamin <spam here.lot> writes:
Walter Bright Wrote:

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

I don't think so. `inout` is needed in D because you get const data from const object because of transitivity, you have nothing like this in C++ POD. One can try to emulate transitive const with corresponding accessors, but is it used in C++ widely?
Nov 09 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Nov 08 2011
parent Kagamin <spam here.lot> writes:
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.
Nov 09 2011
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
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.


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.
Nov 08 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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.


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
Nov 09 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 http://drdobbs.com/blogs/cpp/231902461
 
 Anyone want to do the reddit honors?

On Reddit I see the discussion is a bit about merging of templates that produce the same function code. This is already possible in D, compiling with the LDC1 (and maybe LDC2 too) compiler using the -mergefunc switch. I think according to the C standard all functions must have different function pointers, and I presume D has the same rule (even if I don't remember reading it in the D specs). This problem is solved leaving a tiny stub that just contains a jump instruction for the removed duplicated functions. This jump is probably nearly always correctly "predicted" by the CPU, because it's hard-coded. As far as I know this -mergefunc is not able to remove partially duplicated functions, this is left to future improvements of the LLVM back-end. Bye, bearophile
Nov 09 2011