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

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

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.

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

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

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.

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.

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

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.

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?"