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: Let # be a character, distinct from , such that no legal identifier can begin with #. Then introduce a new set of 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.
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: Let # be a character, distinct from , such that no legal identifier can begin with #. Then introduce a new set of 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. It's not worth it. is ugly. # is ugly. Both add unecessary 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 reserving a set of strings, prefixed with for example #, and take 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 by # and put the existing ones in there. 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:
   is ugly. # is ugly. Both add unecessary characters. 
 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
I agree with the is ugly and # is ugly, but I believe safe, 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:
 I agree with the   is ugly and # is ugly, but I believe  safe, 
  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