If someone is not following the merges, well...  [1] !!

---
Paolo

[1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171@hookshot-fe4-cp1-prd.iad.github.net.mail

On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:
> If someone is not following the merges, well...  [1] !!
>
> ---
> Paolo
>
> [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171@hookshot-fe4-cp1-prd.iad.github.net.mail

I'm running out of ideas for DConf topics.

On 1/26/15 1:50 AM, Brian Schott wrote:
> On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:
>> If someone is not following the merges, well...  [1] !!
>>
>> ---
>> Paolo
>>
>> [1]
>> http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171@hookshot-fe4-cp1-prd.iad.github.net.mail
>>
>
> I'm running out of ideas for DConf topics.

Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei

On Mon, 26 Jan 2015 09:29:40 +0000, Paolo Invernizzi wrote:

i'm scared. does that mean that my rants about "consistency" was sane after all? and now i have to find something else to attack? (sigh) poor me.

On Monday, 26 January 2015 at 09:54:31 UTC, Andrei Alexandrescu wrote:
> On 1/26/15 1:50 AM, Brian Schott wrote:
>> On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:
>>> If someone is not following the merges, well...  [1] !!
>>>
>>> ---
>>> Paolo
>>>
>>> [1]
>>> http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171@hookshot-fe4-cp1-prd.iad.github.net.mail
>>>
>>
>> I'm running out of ideas for DConf topics.
>
> Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei

The extra glyphs add a bit of visual noise, but I think that's balanced out by the better consistency of the language and the growing sphere of functions which can have their attributes inferred.

On 1/26/2015 1:50 AM, Brian Schott wrote:
> I'm running out of ideas for DConf topics.

I don't think there's any risk of bugzilla going down to zero by May :-)

On Monday, January 26, 2015 01:54:36 Andrei Alexandrescu via Digitalmars-d wrote:
> On 1/26/15 1:50 AM, Brian Schott wrote:
> > On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:
> >> If someone is not following the merges, well...  [1] !!
> >>
> >> ---
> >> Paolo
> >>
> >> [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171@hookshot-fe4-cp1-prd.iad.github.net.mail
> >>
> >
> > I'm running out of ideas for DConf topics.
>
> Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei

In theory, the increased consistency is welcome, but the increased visual noise definitely is not.  And if we leave in pure and nothrow without @, then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without @, then we'll be forced to change pretty much every D program in existence.

But It's not like this really improves consistency all that much anyway, because public, protected, package, private, final, override, static, const, immutable, inout, and deprecated all don't have @. So, most function attributes _don't_ have @ on them, and we just added @ to some of them, making things even _less_ consistent. In fact, priore to this, @safe, @trusted, @system, and @property were the _only_ function attributes with @ on them. So, if we really wanted to improve consistency IMHO, we'd get rid of @ from everything that's built-in and leave it for user-defined attributes, but that would break existing code too.

Ultimately, I really don't see this as an improvement, because it really doesn't fix the consistency problem with attributes, and we're either going to have to change existing code or end up with both @pure and pure, and @nothrow and nothrow in the language, which is just ugly. But aside from having duplicate attributes for the same thing, I don't know that it really makes things any worse - though at least before this, we could just say that @property, @safe, @trusted, and @system were oddballs that were added late in the game and that they had @, because we didn't want to add new keywords. With this change, I expect that it will be even less clear which attributes have @ on them and which don't.

Personally, I'd much prefer that we not make this change. It's just shuffling things around in an attempt to make them more consistent while actually making them _less_ consistent.

- Jonathan M Davis

Jonathan M Davis:

> Personally, I'd much prefer that we not make this change. It's just shuffling things around in an attempt to make them more consistent while actually making them _less_ consistent.

So far I agree with Jonathan.

Bye,
bearophile

On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:
> But It's not like this really improves consistency all that much anyway,
> because public, protected, package, private, final, override, static, const,
> immutable, inout, and deprecated all don't have @. So, most function
> attributes _don't_ have @ on them, and we just added @ to some of them,
> making things even _less_ consistent. In fact, priore to this, @safe,
> @trusted, @system, and @property were the _only_ function attributes with @
> on them. So, if we really wanted to improve consistency IMHO, we'd get rid
> of @ from everything that's built-in and leave it for user-defined
> attributes, but that would break existing code too.
> - Jonathan M Davis

At this point, it might be nicer to have only attributes that exists as C++ keywords not having the @ identifier before them.
That is: public, protected, private, override, deprecated, static and const.

But this probably doesn't make much sense now, does it?

+1

On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:
> On Monday, January 26, 2015 01:54:36 Andrei Alexandrescu via Digitalmars-d wrote:
>> On 1/26/15 1:50 AM, Brian Schott wrote:
>> > On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:
>> >> If someone is not following the merges, well...  [1] !!
>> >>
>> >> ---
>> >> Paolo
>> >>
>> >> [1]
>> >> http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171@hookshot-fe4-cp1-prd.iad.github.net.mail
>> >>
>> >
>> > I'm running out of ideas for DConf topics.
>>
>> Heh, I infer that's a good thing. Nevertheless we should probably
>> discuss this and its impact; don't forget we can always undo it before
>> 2.067. Thoughts! -- Andrei
>
> In theory, the increased consistency is welcome, but the increased visual
> noise definitely is not.  And if we leave in pure and nothrow without @,
> then we're going to have code out there doing both, which adds to the
> confusion, and if we deprecate pure and nothrow without @, then we'll be
> forced to change pretty much every D program in existence.
>
> But It's not like this really improves consistency all that much anyway,
> because public, protected, package, private, final, override, static, const,
> immutable, inout, and deprecated all don't have @. So, most function
> attributes _don't_ have @ on them, and we just added @ to some of them,
> making things even _less_ consistent. In fact, priore to this, @safe,
> @trusted, @system, and @property were the _only_ function attributes with @
> on them. So, if we really wanted to improve consistency IMHO, we'd get rid
> of @ from everything that's built-in and leave it for user-defined
> attributes, but that would break existing code too.
>
> Ultimately, I really don't see this as an improvement, because it really
> doesn't fix the consistency problem with attributes, and we're either going
> to have to change existing code or end up with both @pure and pure, and
> @nothrow and nothrow in the language, which is just ugly. But aside from
> having duplicate attributes for the same thing, I don't know that it really
> makes things any worse - though at least before this, we could just say that
> @property, @safe, @trusted, and @system were oddballs that were added late
> in the game and that they had @, because we didn't want to add new keywords.
> With this change, I expect that it will be even less clear which attributes
> have @ on them and which don't.
>
> Personally, I'd much prefer that we not make this change. It's just
> shuffling things around in an attempt to make them more consistent while
> actually making them _less_ consistent.
>
> - Jonathan M Davis