On 28.01.15 14:14, bearophile wrote:
> Dicebot:
>
>> Yes, but it didn't also fix anything, only introduced more ways to do
>> the same thing - without any plans for some consistent model.
>
> One of the rules of the Python Zen:
>
> There should be one-- and preferably only one --obvious way to do it.
>

Yes but also:
Practicality beats purity :)

On Wednesday, 28 January 2015 at 13:58:22 UTC, bearophile wrote:
> The first one (the list comp) is Pythonic, and it's obviously the obvious one :-)
>
> If you want/need to use numpy, the fourth is good.
>
> No problems :-)

Ok, so we agree, but I think the obvious way if we forget about languages would be to combine range with element wise multiplication, e.g. "range(10) .* 0.1".

Good usability often means... stick to common conventions, but be internally consistent. Most language designs fail here by not caring enough for the know-how users bring to the table... :-/

On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
> But in this case I see no improvement that could justify it.

Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388

On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote:
> On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
>> But in this case I see no improvement that could justify it.
>
> Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388

Yes, but as it has been already mentioned in this thread new system is as much inconsistent - it simply has moved 3 of attributes from one "camp" to another. If idea was to separate attributes that affect mangling/type then we still have protection attributes. And with no plans to deprecate old syntax even more inconsistency had been introduced. Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. I don't see any _vision_ behind the change, just moving bits around.

It is not well-thought.

On 1/28/15 4:11 AM, Dicebot wrote:
> On Tuesday, 27 January 2015 at 10:50:53 UTC, Walter Bright wrote:
>> This change didn't break a single line in the libraries or the test
>> suite.
>
> Yes, but it didn't also fix anything, only introduced more ways to do
> the same thing - without any plans for some consistent model. It is
> simply moving things around for the sake of marking some bugzilla report
> as closed - there is no consistent rationale for applying @ to
> attributes available.
>
> Just the fact that change can't possibly break anything doesn't mean it
> is can't have negative value. It _may_ have some well-though rationale
> behind I am failing to spot but that is not presented to users in any way.

Change has been reverted. -- Andrei

On Wednesday, 28 January 2015 at 14:59:48 UTC, Andrei Alexandrescu wrote:
> Change has been reverted. -- Andrei

Thank you very much.

Just to be perfectly clear : I am not against consolidating attributes or even breaking things. Only thing I want is for such changes to be done _simultaneously_ with some more detailed rationale which can be linked from a changelog and would explain everyone outside of this NG what the change is about.

It is quite likely that trying to write such rationale will highlight more internal inconsistencies than any discussion could.

On Wednesday, January 28, 2015 14:41:08 Dicebot via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote:
> > On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
> >> But in this case I see no improvement that could justify it.
> >
> > Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388
>
> Yes, but as it has been already mentioned in this thread new system is as much inconsistent - it simply has moved 3 of attributes from one "camp" to another. If idea was to separate attributes that affect mangling/type then we still have protection attributes. And with no plans to deprecate old syntax even more inconsistency had been introduced. Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. I don't see any _vision_ behind the change, just moving bits around.
>
> It is not well-thought.

Exactly. It's not like this is simply a discussion of whether a change which makes the language more consistent is worth the breaking changes that it causes. Rather, The change doesn't actually fix anything. It just moves stuff around. If more things were moved around, then maybe they'd become more consistent and would actually help the situation, but that's not what's happened. A few were attributes moved from one camp to the other with no real plan, and because it took attributes from the smaller camp and put them in the larger one, it's actually decreasing consistency and making the situation worse rather than improving it.

If we're going to shuffle attributes around, we need to do it in a way that actually follows a plan and makes the language more consistent. That's not what's happening here. We either need to come up with a complete plan for shuffling attributes around in a way that will actually make them fully consistent, or we need to revert these changes and stick with the status quo. Anything else just shuffles things around without fixing the problem, and it increases confusion in the process.

And honestly, after several discussions on this in the past, I don't think that it's actually possible to make the attributes fully consistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expects (e.g. @ on a whole bunch of keywords like private or final that other languages don't put @ on and which none of the current D literature or code out there puts @ on). I think that this is a case of folks trying to shuffle things around to fix something that just can't be fixed. At best, it'll just end up being ugly in a different way.

- Jonathan M Davis

On Wednesday, January 28, 2015 06:59:49 Andrei Alexandrescu via Digitalmars-d wrote:
>
> Change has been reverted. -- Andrei

Yay!

- Jonathan M Davis

On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis wrote:
> consistent. They're
> always going to be inconsistent in one way or another, even if it's simply
> because they don't match what anyone coming from other languages expects

The logical conclusion from that statement would be that D semantics are fundamentally broken...

On Wednesday, 28 January 2015 at 14:41:09 UTC, Dicebot wrote:
> And with no plans to deprecate old syntax even more inconsistency had been introduced.

When the problem arises, then.

> Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords.

Same for any symbol. Do you have a solution?

> I don't see any _vision_ behind the change, just moving bits around.
>
> It is not well-thought.

@pure, @nothrow and @return are relatively obscure attributes, so if they change, it should cause minor commotion. If you want to overhaul everything, you can propose a DIP.