www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - All function attributes possible with " "?

reply 01010100b <caveman1917 hotmail.com> writes:
On the wiki there is an argument given for why not to allow " " 
on function attributes which are keywords, however it seems to 
include a reasoning error.

This is the argument:

"Why don't we just allow an ' ' character on all function 
attributes so it looks consistent?

To appreciate the answer for this remember that the original 
problem is a matter of consistency. It's inconsistent that some 
function attributes use an ' ' character and some don't. If D 
supported putting an ' ' character on the function attributes 
that are also keywords, then this moves the inconsistency 
somewhere else. Since keywords are re-used all over the place, 
some instances of the keyword will require an ' ' and some will 
not"

 From here: https://wiki.dlang.org/Language_Designs_Explained

The error being that the "allowed" in the question is changed to 
"required" in the answer. Just because you would be allowed to 
use " pure function()" does not imply that you are required to do 
so, you could still also be allowed to use "pure function()".

So why not let all function attributes which are keywords also be 
allowed to be used with a " " prefixed?
Dec 13 2016
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:

 So why not let all function attributes which are keywords also 
 be allowed to be used with a " " prefixed?


Because it just creates yet another way to make one person's code 
look drastically different from another with no real gain? It 
would result in yet more style arguments without solving 
anything. And it wouldn't even reduce the number of quesions 
about it, because then we'd get a bunch of questions about stuff 
like what the difference between pure and  pure is.

Also, would you even allow   on stuff like static or const? Those 
can be used elsewhere in places where nothing has   on it, 
creating yet more inconsistencies if you allowed it in those 
places, and if you allowed   when they were used on functions and 
not elsewhere, that's yet another inconsistency.

The _only_ way to eliminate all of the inconsistencies with   is 
to get rid of it from everywhere but UDAs, and turn all of those 
built-in attributes into full-blown keywords, and we're simply 
not going to do that. Any other solution is just moving the 
inconsistencies around.

I say that when dealing with the built-in attributes, just treat 
  like another letter in the keyword, learn it, and move on.

- Jonathan M Davis
Dec 13 2016
next sibling parent HaraldZealot <harald_zealot tut.by> writes:
On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis 
wrote:

 On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:

 The _only_ way to eliminate all of the inconsistencies with   
 is to get rid of it from everywhere but UDAs, and turn all of 
 those built-in attributes into full-blown keywords, and we're 
 simply not going to do that. Any other solution is just moving 
 the inconsistencies around.


Almost. We have other very promising options: make them 
context-keyword (this possibility already one of considerable 
solution for "body" DIP). If we introduce context-keyword then 
language designer are freed to add any new language defined 
attributes, which will be not clashed with user defined 
attributes, and OTOH not introduce full-blown keyword which clash 
with other user symbol. But as preliminary work we need probably 
to favour one style of context (e.g. all attributes appears after 
function declaration not before, there is also (possible 
solvable) problem how to interpret no-one function declaration 
`pure:` and `pure{}`).

Probably we can go even further: split the whole set of keywords 
into 3 subsets: full-blown keyword (like `if`, `while` etc, 
probably it also time to restyle `traits`), context-keywords 
(like mentioned attribution, probably even `private`, `public` 
etc can be made context-keyword, and even further `const`, 
`immutable` etc) but with very stric and i/e quick parse-able 
context, and intrinsic types (`int`, `ulong` etc, because some of 
them especially `real` should be made platform specific) swhich 
almost full-blown keyword, with only point that you not 
guaranteed have all of them  on your platform
Dec 14 2016
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis 
wrote:

 I say that when dealing with the built-in attributes, just 
 treat   like another letter in the keyword, learn it, and move 
 on.


**Applause**

This is such a small thing and it is no problem at all to get 
used to.  Much better to focus on things that can really make a 
difference.
Dec 14 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton 
Wakeling wrote:

 On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M 
 Davis wrote:

 I say that when dealing with the built-in attributes, just 
 treat   like another letter in the keyword, learn it, and move 
 on.


 **Applause**

 This is such a small thing and it is no problem at all to get 
 used to.  Much better to focus on things that can really make a 
 difference.


exactly the kind of logic that made c++.

if someone have to "get used" to something in the language, and 
there is no way to logically deduce it, the language has A HUGE 
PROBLEM. there just can't be more important things. 'cause it 
doesn't matter how much features your language has: if it require 
random memorization, it won't attract people. with c and c++ we 
haven't much choice, but now there are alot of languages.

sadly, any attempt to sanitize D is dismissing with "small thing" 
argument. and then we keep trying to explain why " " in 
attributes is random, why `auto` is not allowed in `foreach`, and 
so on. and there is no real answer except "it is such a small 
thing! get used to it!" and that doesn't work. why newcomer have 
to "get used" to something right from the start, even before he 
developed some relations with the language?

"just get used to that small thing" is a big thing that ruins D.
Dec 14 2016
next sibling parent HaraldZealot <harald_zealot tut.by> writes:
On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote:

 On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton 
 Wakeling wrote:

 On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M 
 Davis wrote:

 I say that when dealing with the built-in attributes, just 
 treat   like another letter in the keyword, learn it, and 
 move on.


 **Applause**

 This is such a small thing and it is no problem at all to get 
 used to.  Much better to focus on things that can really make 
 a difference.


 exactly the kind of logic that made c++.

 ...

 "just get used to that small thing" is a big thing that ruins D.


+1
Dec 14 2016
prev sibling next sibling parent Bauss <jj_1337 live.dk> writes:
On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote:

 On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton 
 Wakeling wrote:

 [...]


 exactly the kind of logic that made c++.

 [...]


This. This. This.
Dec 14 2016
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote:

 On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton 
 Wakeling wrote:

 On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M 
 Davis wrote:

 I say that when dealing with the built-in attributes, just 
 treat   like another letter in the keyword, learn it, and 
 move on.


 **Applause**

 This is such a small thing and it is no problem at all to get 
 used to.  Much better to focus on things that can really make 
 a difference.


 exactly the kind of logic that made c++.

 if someone have to "get used" to something in the language, and 
 there is no way to logically deduce it, the language has A HUGE 
 PROBLEM. there just can't be more important things. 'cause it 
 doesn't matter how much features your language has: if it 
 require random memorization, it won't attract people. with c 
 and c++ we haven't much choice, but now there are alot of 
 languages.


The reality of the matter is that unless you're willing to 
frequently break everyone's code, at some point, you're going to 
be stuck with imperfections in the language. The only way to 
avoid that would be to get it perfect at the start, and that 
obviously never happens. If we keep making breaking changes, we 
will never have a significant user base - especially if the 
changes are stylistic rather than providing real, technical value 
that fixes problems that people have with their code.

Some breaking changes are still worth making, because they 
provide enough value, but the older the language gets and the 
more people there are using it, the higher the bar gets for 
breaking changes. And yes, that risks creating a bit of a mess of 
a language like happened with C++. And eventually, someone will 
go and create D++ or E or whatever to replace D, because they 
want something better. And they'll get improvements along with a 
new set of mistakes that will result in ugliness in the language. 
And eventually, someone will decide to come up with a language 
that improves on that one. Etc.

D is better than C++, because we were able to learn from its 
mistakes, but that doesn't mean that we're not doomed to have the 
same sort of cruft or inelegance problems that C++ has, much as 
we'd like to avoid it.


 "just get used to that small thing" is a big thing that ruins D.


Perhaps, but if so, every language that gets any kind of real 
world usage is doomed to be ruined. At some point, every real 
world language is going to have something that can't be fixed 
without breaking everyone's code and isn't worth breaking 
everyone's code over. And at some point, in order to add a new 
feature, ugliness is going to creep into the language, because it 
was tacked on later, and the rest of the language can't be 
changed in a way that would break code. Yes, that sucks, but 
that's life.

- Jonathan M Davis
Dec 14 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 14 December 2016 at 21:02:09 UTC, Jonathan M Davis 
wrote:

 If we keep making breaking changes, we will never have a 
 significant user base


so the core issue is a direction D developement should go:
1) have a good language, or
2) have big userbase.

it looks like those goals are in conflict now. while i can see 
how userbase matters, i also can't see how it matters for me -- 
it turns out that i got a mediocre language as a result. well, 
there are alot of "acceptable" languages out there, and c++ has a 
huge userbase and a huge codebase, so it will always win here. 
the only way for D to win (as i see it) is to deliver a better 
language. and that means dropping support for old code from time 
to time, not to stick with bad design forever. also, tools like 
dfix can be made to "upgrade" code.

so far being "stable" didn't brought Bick Bucks or Big Corporate 
Support to D. yet instead of using that to advance the language, 
to redesign features and so on, D is stuck in a hope of getting 
some Big Future Support. i may be completely wrong, of course, 
but i see the unique strength that D can exploit: the ability to 
change.

sure, turning D into "moving target" will make some older code 
invalid. but if the author doesn't want to maintain his code, is 
there any real reason to use it? with automatic upgrade utility 
it wouldn't be that hard to keep the code up-to-date.

i believe that pediodical "cleanups" will make D better, and will 
win more users in the long run. so i will continue advocating 
"moving target" concept from time to time. ;-)
Dec 14 2016
next sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 12/14/16 2:34 PM, ketmar wrote:

 On Wednesday, 14 December 2016 at 21:02:09 UTC, Jonathan M Davis wrote:

 If we keep making breaking changes, we will never have a significant
 user base


 so the core issue is a direction D developement should go:
 1) have a good language, or
 2) have big userbase.

 it looks like those goals are in conflict now. while i can see how
 userbase matters, i also can't see how it matters for me -- it turns out
 that i got a mediocre language as a result. well, there are alot of
 "acceptable" languages out there, and c++ has a huge userbase and a huge
 codebase, so it will always win here. the only way for D to win (as i
 see it) is to deliver a better language. and that means dropping support
 for old code from time to time, not to stick with bad design forever.
 also, tools like dfix can be made to "upgrade" code.

 so far being "stable" didn't brought Bick Bucks or Big Corporate Support
 to D. yet instead of using that to advance the language, to redesign
 features and so on, D is stuck in a hope of getting some Big Future
 Support. i may be completely wrong, of course, but i see the unique
 strength that D can exploit: the ability to change.

 sure, turning D into "moving target" will make some older code invalid.
 but if the author doesn't want to maintain his code, is there any real
 reason to use it? with automatic upgrade utility it wouldn't be that
 hard to keep the code up-to-date.

 i believe that pediodical "cleanups" will make D better, and will win
 more users in the long run. so i will continue advocating "moving
 target" concept from time to time. ;-)


I've noticed that recent languages like Go and Swift are trying to have 
both by bundling a code fixer with new versions of their language. I 
have a hard time seeing the downsides of that.
Dec 14 2016
parent 01010100b <caveman1917 hotmail.com> writes:
On Wednesday, 14 December 2016 at 21:44:40 UTC, David Gileadi 
wrote:

 I've noticed that recent languages like Go and Swift are trying 
 to have both by bundling a code fixer with new versions of 
 their language.


An automated code fixer in this case would be easy. Before 
looking up on the wiki why we couldn't do  pure  nogc func() I 
considered I could just add a pre-build step which does a string 
replacement on the source code from " keyword" to "keyword" for 
each keyword which can be used as a function attribute.

Given a change to allowing " keyword", existing source code would 
just need to be checked for containing " keyword" and prompting 
to replace it with something else.
Dec 14 2016
prev sibling parent KaattuPoochi <visionofarun gmail.com> writes:
On Wednesday, 14 December 2016 at 21:34:20 UTC, ketmar wrote:

 the only way for D to win (as i see it) is to deliver a better 
 language. and that means dropping support for old code from 
 time to time, not to stick with bad design forever. also, tools 
 like dfix can be made to "upgrade" code.


Can't agree more. Isn't this why D was created a decade ago? Why 
is it wrong to fix them and revive? Orthogonality and consistency 
are the things where D should focus on improving. The ripples of 
lack of vision are already evident in D. Missing them would make 
D's ambition of replacing C++ a mere mediocre.
Dec 14 2016
prev sibling parent Yuxuan Shui <yshuiv7 gmail.com> writes:
On Wednesday, 14 December 2016 at 21:02:09 UTC, Jonathan M Davis 
wrote:

 On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote:

 [...]


 If we keep making breaking changes, we will never have a 
 significant user base - especially if the changes are stylistic 
 rather than providing real, technical value that fixes problems 
 that people have with their code.


Rust? It gained a lot of user base even when it was doing a lot 
breaking changes.


 - Jonathan M Davis
Dec 14 2016
prev sibling next sibling parent reply 01010100b <caveman1917 hotmail.com> writes:
On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis 
wrote:

 On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:

 So why not let all function attributes which are keywords also 
 be allowed to be used with a " " prefixed?


 Because it just creates yet another way to make one person's 
 code look drastically different from another with no real gain? 
 It would result in yet more style arguments without solving 
 anything. And it wouldn't even reduce the number of quesions 
 about it, because then we'd get a bunch of questions about 
 stuff like what the difference between pure and  pure is.


If the answer is "no difference" then I don't see the problem.


 Also, would you even allow   on stuff like static or const?


Why not?


 Those can be used elsewhere in places where nothing has   on 
 it, creating yet more inconsistencies if you allowed it in 
 those places, and if you allowed   when they were used on 
 functions and not elsewhere, that's yet another inconsistency.


That may be so, but why should I prefer this inconsistency:

pure final  nogc func();
final class G{}

over this one? :

 pure  final  nogc func();
final class G{}

Also, allowing keywords to be written with " " prefixed would 
allow consistent use as well, such as

 pure  final  nogc func();
 final class G{}

Right now we are locked into a certain inconsistency, at least 
with the proposed change we'd be able to construct one ourselves 
should we want to do so.


 The _only_ way to eliminate all of the inconsistencies with   
 is to get rid of it from everywhere but UDAs, and turn all of 
 those built-in attributes into full-blown keywords, and we're 
 simply not going to do that. Any other solution is just moving 
 the inconsistencies around.


That is false, you can clearly also remove all inconsistencies by 
getting rid of full-blown keywords as function attributes and 
turn all of them into built-in attributes. Much less likely to 
break existing code as well.


 I say that when dealing with the built-in attributes, just 
 treat   like another letter in the keyword, learn it, and move 
 on.


The point is that it is easier to learn if you can just treat   
like another letter in _every_ keyword, that way you don't have 
to distinguish between distinct sets of function attributes the 
distinction of which is basically "historical baggage".
Dec 14 2016
next sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 14 December 2016 at 19:22:12 UTC, 01010100b wrote:

 On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M 
 Davis wrote:



 Also, would you even allow   on stuff like static or const?


 Why not?


Really?


  pure  final  nogc func();
  final class G{}


                      

And, "final" is not a D only thing
Dec 14 2016
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 14 December 2016 at 19:22:12 UTC, 01010100b wrote:

 On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M 
 Davis wrote:

 On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:

 So why not let all function attributes which are keywords 
 also be allowed to be used with a " " prefixed?


 Because it just creates yet another way to make one person's 
 code look drastically different from another with no real 
 gain? It would result in yet more style arguments without 
 solving anything. And it wouldn't even reduce the number of 
 quesions about it, because then we'd get a bunch of questions 
 about stuff like what the difference between pure and  pure is.


 If the answer is "no difference" then I don't see the problem.


The problem is that you're _still_ getting questions about  , 
which is the real problem with some attributes having it and some 
not. It creates confusion. Actually learning which ones have   or 
not really isn't a big deal.


 Also, would you even allow   on stuff like static or const?


 Why not?


Because it's adding yet another inconsistency in the places that 
don't involve function attributes. After all, static and cost 
both get used in contexts where keywords such as auto and enum 
get used (neither of which are function attributes), and they 
don't have  . Or are you suggesting that we slap   on all 
keywords? All you're doing is shuffling inconsistencies around. 
But even worse, you're then introducing yet another way to do 
exactly the same thing in D without it adding any new 
functionality. There will be questions over what the difference 
between  pure and pure is. There will be questions about why you 
can use both  pure and pure, but you're forced to use  safe 
instead of safe. There will be yet more arguments over coding 
style and whether it's better to use  pure or pure.


 I say that when dealing with the built-in attributes, just 
 treat   like another letter in the keyword, learn it, and move 
 on.


 The point is that it is easier to learn if you can just treat   
 like another letter in _every_ keyword, that way you don't have 
 to distinguish between distinct sets of function attributes the 
 distinction of which is basically "historical baggage".


Except that it isn't easier to learn, because you still have 
stuff like pure and nothrow in addition to their   counterparts, 
meaning that there's _more_ to learn, and you get additional 
confusion and arguments over when   is used or isn't. The 
optional aspect of this makes it terrible aside from the fact 
that it let's you do what you want with your code. It's terrible 
for learning, and it's terrible for collaboration. And even if we 
made the changes that you're suggesting, we'd _still_ have to 
give the explanation about "historical baggage" because of the 
inconsistencies that would remain.

If we could agree on a set of changes to make that made all of 
this consistent, and we were willing to pay the cost of the 
breakage that would result, then that would be one thing, but 
optional syntax that looks like it should have a semantic 
difference when it doesn't is just going to make the confusion 
and questions worse, and it will add more fuel to the fire in 
code style arguments.

All your suggestion would really do would be to make it so that 
in your own personal code, you could choose to use   on 
everything and have it consistent in that way if that's what you 
prefer. It makes everything else worse.

- Jonathan M Davis
Dec 14 2016
parent reply 01010100b <caveman1917 hotmail.com> writes:
On Wednesday, 14 December 2016 at 20:41:57 UTC, Jonathan M Davis 
wrote:

 Because it's adding yet another inconsistency in the places 
 that don't involve function attributes. After all, static and 
 cost both get used in contexts where keywords such as auto and 
 enum get used (neither of which are function attributes), and 
 they don't have  . Or are you suggesting that we slap   on all 
 keywords? All you're doing is shuffling inconsistencies around.


Actually slapping   on all keywords would remove the 
inconsistency altogether, even if that isn't necessarily what I 
favour. Keywords which are also function attributes would seem a 
better set to allow   on. While it is true that this reduced set 
of keywords would be "shuffling an inconsistency around" that 
still leaves open whether this inconsistency:

final pure  nogc func()
final class G{}

is preferable over this one:

 final  pure  nogc func()
final class G{}


 But even worse, you're then introducing yet another way to do 
 exactly the same thing in D without it adding any new 
 functionality. There will be questions over what the difference 
 between  pure and pure is. There will be questions about why 
 you can use both  pure and pure, but you're forced to use  safe 
 instead of safe. There will be yet more arguments over coding 
 style and whether it's better to use  pure or pure.


There will always be arguments over coding style, but this isn't 
one of them, it's about language design.


 Except that it isn't easier to learn, because you still have 
 stuff like pure and nothrow in addition to their   
 counterparts, meaning that there's _more_ to learn


Why would you need to learn pure or nothrow in addition to their 
  counterparts?


 It's terrible for learning


No it isn't, less needs to be learned. You could think of the 
non-  variants as deprecated.


 and it's terrible for collaboration.


No more so than deciding on a variable naming or brace style.


 If we could agree on a set of changes to make that made all of 
 this consistent, and we were willing to pay the cost of the 
 breakage that would result, then that would be one thing, but 
 optional syntax that looks like it should have a semantic 
 difference when it doesn't is just going to make the confusion 
 and questions worse, and it will add more fuel to the fire in 
 code style arguments.


If you want to eliminate inconsistency while only paying the cost 
of breakage once, then how about this:



#pure, #nogc, #const, #nothrow etc, which can be used as 
attributes. Deprecate the previous syntax. After this language 
designers can add as many #attribute keywords as they want in the 
future, since they will never clash with users' identifiers by 
definition.
Dec 14 2016
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, 15 December 2016 at 00:08:12 UTC, 01010100b wrote:

 On Wednesday, 14 December 2016 at 20:41:57 UTC, Jonathan M 
 Davis wrote:
 Actually slapping   on all keywords would remove the 
 inconsistency altogether, even if that isn't necessarily what I 
 favour. Keywords which are also function attributes would seem 
 a better set to allow   on. While it is true that this reduced 
 set of keywords would be "shuffling an inconsistency around" 
 that still leaves open whether this inconsistency:

 final pure  nogc func()
 final class G{}

 is preferable over this one:

  final  pure  nogc func()
 final class G{}


How on earth is that preferable? In the first case, every single 
attribute is always the same. In the second, sometimes they have 
 , sometimes they don't, and programmers would have to know when 
which was used. And as soon as you slap   on attributes that 
exist in other languages, you've made D harder to learn, and 
you've made it harder to port code from other languages to D.


 But even worse, you're then introducing yet another way to do 
 exactly the same thing in D without it adding any new 
 functionality. There will be questions over what the 
 difference between  pure and pure is. There will be questions 
 about why you can use both  pure and pure, but you're forced 
 to use  safe instead of safe. There will be yet more arguments 
 over coding style and whether it's better to use  pure or pure.


 There will always be arguments over coding style, but this 
 isn't one of them, it's about language design.


If you optionally allow   on attributes, it definitely becomes a 
question of coding style - e.g. some code will use pure and some 
will use  pure. And you get all of the arguments over whether a 
codebase should use   or not and whether it's acceptable to mix 
them. The only way that this does not become a coding style 
question is if we change the keywords rather than having two 
versions of them. Optional syntax pretty much always leads to 
arguments about coding style.


 Except that it isn't easier to learn, because you still have 
 stuff like pure and nothrow in addition to their   
 counterparts, meaning that there's _more_ to learn


 Why would you need to learn pure or nothrow in addition to 
 their   counterparts?


 It's terrible for learning


 No it isn't, less needs to be learned. You could think of the 
 non-  variants as deprecated.


Except that they wouldn't be. It would be completely up to 
programmers to use one or the other.  So, anyone using D would 
have to be familiar with both. And _not_ having   is what all 
existing code does and what many programmers will prefer. So, 
best case, both would be very common, and there's a decent chance 
that the   versions would always be in the minority. Changing 
them only works if you force the change, which means _actually_ 
deprecating and removing the non-  versions and breaking most D 
programs in the process.


 and it's terrible for collaboration.


 No more so than deciding on a variable naming or brace style.


Except that we don't need to add yet another coding standard 
issue to argue over. This does _nothing_ except maybe improve 
your ability to have aesthetically pleasing code if you think 
that slapping   on all of the attributes is aesthetically 
pleasing (and a number of folks think that the  s are downright 
ugly). Let's please not add optional syntax to the language over 
an aesthetic issue.


 If we could agree on a set of changes to make that made all of 
 this consistent, and we were willing to pay the cost of the 
 breakage that would result, then that would be one thing, but 
 optional syntax that looks like it should have a semantic 
 difference when it doesn't is just going to make the confusion 
 and questions worse, and it will add more fuel to the fire in 
 code style arguments.


 If you want to eliminate inconsistency while only paying the 
 cost of breakage once, then how about this:



 keywords #pure, #nogc, #const, #nothrow etc, which can be used 
 as attributes. Deprecate the previous syntax. After this 
 language designers can add as many #attribute keywords as they 
 want in the future, since they will never clash with users' 
 identifiers by definition.


Except that most of us _don't_ want to break our code over this. 

characters. Aesthetically speaking, it would be _way_ better ts 
have them all be keywords, but we didn't want to have that many 
keywords. And regardless, changing code over what attributes are 
named really dosen't add much value. Sure, it would be nice to 
not have to explain to newbies why some attributes have   and 
some don't. Having more consistency with regards to   would be 
nice. But at this point, it is _not_ worth breaking code over And 
I would be stunned if you could convince Walter or Andrei that it 
is. This is _exactly_ the sort of change that they think is 
detrimental to the language. It's an aesthetic issue, not a 
technical one. It doesn't cause problems beyond the fact that it 
spmetimes has to be explained to newbies, because they figure 
that the   must mean something, when it really doesn't. And 
changing what we do with   would arguably make the language 
_less_ visually appealing. So, it's not like we even all agree 
that such a change is even nice in principle. If we all had full 
agreement on a new syntax and that it was worth breaking our code 
over, then maybe, but you're not going to get any kind of 
consensus on what the syntax should be let alone on the change 
being worth the breakage.

- Jonathan M Davis
Dec 14 2016
next sibling parent reply 01010100b <caveman1917 hotmail.com> writes:
On Thursday, 15 December 2016 at 03:56:56 UTC, Jonathan M Davis 
wrote:

 This does _nothing_ except maybe improve your ability to have 
 aesthetically pleasing code if you think that slapping   on all 
 of the attributes is aesthetically pleasing (and a number of 
 folks think that the  s are downright ugly).


This doesn't follow, one can think that all  s is downright ugly 
(I think so for example) yet still consider it _less_ ugly than 
an effectively random mix of some with   and some without  , ie 
if your preferences are: no   > all   > mixed.


 It doesn't cause problems beyond the fact that it spmetimes has 
 to be explained to newbies, because they figure that the   must 
 mean something, when it really doesn't.


It will cause a problem every time you want to add a new 
attribute to the language.

Right now it seems the worst decision was taken. If you want the 
language, in its current state, to remain fixed then you might as 
well take the hit and change the  attributes to keywords and be 
done with it once and for all. If you want the language to be 
extensible with future attributes, then you're better off 

the hit now so that you won't incur a breaking change for every 
single future attribute which might get added.

Given that this situation arose exactly because people kept 
adding attributes to the language after the list of keywords got 
fixed, I'm going to assume that it is likely people will want to 
do so in the future as well.

And if the goal is greater adoption of the language then I don't 
think it's true that only technical changes matter. Going by the, 
admittedly small, sample of myself the problem is not not being 
able to learn which attributes to write with  , but that this 
just screams "bad design!" at me. Which then leads me to wonder 
"if I invest more into learning and experimenting with this 
language to see if it can solve the problem I want it to solve, 
how likely will it be that I will run into more such things which 
then eventually lead me to reject the language in favour of 
another alternative, thereby wasting my investment in it?"
Dec 14 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 15 December 2016 at 06:40:06 UTC, 01010100b wrote:

 And if the goal is greater adoption of the language then I 
 don't think it's true that only technical changes matter. Going 
 by the, admittedly small, sample of myself the problem is not 
 not being able to learn which attributes to write with  , but 
 that this just screams "bad design!" at me. Which then leads me 
 to wonder "if I invest more into learning and experimenting 
 with this language to see if it can solve the problem I want it 
 to solve, how likely will it be that I will run into more such 
 things which then eventually lead me to reject the language in 
 favour of another alternative, thereby wasting my investment in 
 it?"


hear, hear! this is what i am screaming about all the time: 
requiring each newcomer to perform leap of faith even before he 
felt in love with D! ;-)

btw, i'm using D exclusively for all my programming tasks 
(including scripts i used to write in sh ;-) for several years 
now, and i still have to stop and thing where to put that " " 
sometimes. 'cause it is impossible to deduce, and i am very bad 
in memorizing arbitrary non-logical things.
Dec 15 2016
prev sibling next sibling parent reply 01010100b <caveman1917 hotmail.com> writes:
On Thursday, 15 December 2016 at 03:56:56 UTC, Jonathan M Davis 
wrote:

 How on earth is that preferable?


Sorry, forgot to actually answer your question. It is preferable 
since it is implied by a simple rule (function attributes go with 
 ) rather than rote learning of effectively random historical 
data.

But even if you don't think that's preferable, there's still a 
difference between having a different preference and having one 
preference actually being enforced by the language. In terms of 
coding style, nobody expects a language to enforce a certain 
variable naming convention either.

And this particular change would probably not incur any breakage 
of existing code, unless people happen to be using UDAs with the 
same name as function attribute keywords. It would also, if 
absolute lack of inconsistency is your only determinant, allow 
for this:

 pure  final  nogc func()
 final class G{}

which does fit your stated requirement.
Dec 14 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 15 December 2016 at 07:13:18 UTC, 01010100b wrote:

 And this particular change would probably not incur any 
 breakage of existing code, unless people happen to be using 
 UDAs with the same name as function attribute keywords.


...which is impossible, 'cause keyword can be used as identifier.
Dec 15 2016
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 15 December 2016 at 10:50:39 UTC, ketmar wrote:

 On Thursday, 15 December 2016 at 07:13:18 UTC, 01010100b wrote:

 And this particular change would probably not incur any 
 breakage of existing code, unless people happen to be using 
 UDAs with the same name as function attribute keywords.


 ...which is impossible, 'cause keyword can be used as 
 identifier.


CAN'T, of course. sorry.
Dec 15 2016
prev sibling parent 01010100b <caveman1917 hotmail.com> writes:
On Thursday, 15 December 2016 at 10:50:39 UTC, ketmar wrote:

 On Thursday, 15 December 2016 at 07:13:18 UTC, 01010100b wrote:

 And this particular change would probably not incur any 
 breakage of existing code, unless people happen to be using 
 UDAs with the same name as function attribute keywords.


 ...which is impossible, 'cause keyword can be used as 
 identifier.


Ah yes, true. Then we have

1. Allow   on all function attribute keywords.
2. Allow   on all keywords.

Neither of these is a breaking change, however future attributes 
which might get added will be a breaking change each.

And we have

3. Remove the   and make keywords like nogc etc.
4. Add a set of strings of "language defined attributes" prefixed 


Both of these are breaking. 3. is the "prettiest" but would give 
huge issues with possible future attributes. 4. is the most 
general and future-looking, so that future attributes will never 
require a breaking change.
Dec 15 2016
prev sibling parent reply Bauss <jj_1337 live.dk> writes:
On Thursday, 15 December 2016 at 03:56:56 UTC, Jonathan M Davis 
wrote:


 Aesthetically speaking, it would be _way_ better ts have them 
 all be keywords, but we didn't want to have that many keywords.

 - Jonathan M Davis



 nogc and  property should have been keywords.

A personal opinion of mine though is that  safe shouldn't have 
existed and should have been the default for functions, where a 
 unsafe should have existed in its place.

That's a design choice ex. Rust does better than D. It provides 
safety by default, where in D you have to enable safety.
Dec 15 2016
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 15 December 2016 at 08:48:10 UTC, Bauss wrote:


  nogc and  property should have been keywords.


Sometimes I like to imagine I could get in a time machine and 
make things better.

But in the real world, I more and more prefer to focus on the 
important things.
Dec 15 2016
prev sibling parent Yuxuan Shui <yshuiv7 gmail.com> writes:
On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis 
wrote:

 On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:

 So why not let all function attributes which are keywords also 
 be allowed to be used with a " " prefixed?





 Also, would you even allow   on stuff like static or const?


Actually, allowing   will reduce some confusion here.

 const T memberFunc(); // This function takes const(this), 
returns int
const T memberFunc(); // This function returns const(int)

Whereas now the second one is actually taking const(this) and 
returning int, which is quite surprising to new users coming from 
C/C++.


 - Jonathan M Davis
Dec 14 2016
prev sibling parent Gary Willoughby <dev nomad.so> writes:
On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:

 On the wiki there is an argument given for why not to allow " " 
 on function attributes which are keywords, however it seems to 
 include a reasoning error.


Related DIP: https://wiki.dlang.org/DIP64
Dec 16 2016