On 2015-01-27 17:49, Jonathan M Davis via Digitalmars-d wrote:

> IMHO, if we have to search for a way to make them consistent, then there's
> no point. We're just going to end up with making things more consistent in
> one way and less in another without necessarily making it any easier for
> anyone to keep track of, so we'd just be shuffling things around. I think
> that there needs to be a clear and solid benefit to changing which
> attributes have @ and which don't, or we shouldn't mess with them.

We could change all attributes to be compiler recognized UDA's, which would require prefixing them with @. All current attributes would be removed. This is of course a major breaking change and will not happen.

Since they would be UDA's it would be possible to disambiguate with other UDA's with the same name in another module.

-- 
/Jacob Carlborg

On Tuesday, 27 January 2015 at 18:21:37 UTC, Nick Treleaven wrote:
> On 27/01/2015 18:01, Jonathan Marler wrote:
>> On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote:
>>> On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
>>>> abstract also applies to classes, as does final.
>>>
>>> Yes, but they actually only affect the *functions* belonging to the
>>> class, not the variables. A class is not a variable.
>>>
>>
>> I think you may have missed the point.  I believe what Jonathan is
>> saying is that if you turn abstract into @abstract then you have to
>> consider how to solve the "abstract class" issue.  Do you change it to:
>>
>> @abstract class ?
>
> Yes, because it affects the class's functions, not its variable members.
>
>> Same thing with final.  Since the same keywords are used in a lot of
>> different contexts, if you change how it is used in one context then
>> it's going to be inconsistent with how it's used in the other contexts
>> (like with a function or a class).  Then if you want consistency (which
>> is the point of why we are discussing this change in the first place)
>> you have to change every context it is used in. If you follow through
>> with your proposal, you'll end up putting a '@' character before almost
>> every keyword in the language
>
> In that case I don't think you've really grokked my proposal. It only requires 5 changes to attributes for consistency (and that's counting @pure and @nothrow).

Problem Summary: Using an '@' symbol for some function attributes and not others is weird.

void foo() pure @safe const;

Current Reason:  keywords don't use a '@' and non-keywords use a '@'

Your Solution: Have attributes that apply to variables use no '@' and all other attributes use a '@'.

You've changed the cutoff from "keywords" to "whether or not they apply to variables".  How does this solve the original problem (stated above)?

void foo() @pure @safe const;
// OR
public @pure final @safe foo();

How is this more consistent? This doesn't solve the problem is just shuffles around the cases when we use '@' and when we don't.

Note: not to mention that it still looks horrible to use '@'.  There's no reason the language needs to require a '@' on a keyword.  The only reason is to make things consistent but if you're not making things more consistent, as shown above.

Jonathan M Davis via Digitalmars-d píše v Út 27. 01. 2015 v 08:49 -0800:
> On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:
> > On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
> > > You're right. I forgot about those two. But it's still the case that the number of function attributes that don't have @ on them is_far_  greater than the number of those that do.
> >
> > But I explained that most function attributes don't only apply to functions but to variables as well:
> >
> > public, protected, package, private, static, const, immutable, inout, and deprecated
> >
> > So it can be consistent that the above don't use @.
> >
> > These only affect functions, not variables, so should be @attributes IMO:
> >
> > final, override, abstract
> >
> > These affect both:
> >
> > return, ref
> >
> > So if we want some kind of consistency, we can achieve it by adding @ for final, override, abstract, and removing it for 'return'.
> 
> abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have @ on them to avoid requiring a keyword (which is why we have @ on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart.
> 
> IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have @ and which don't, or we shouldn't mess with them.

Exactly I do not think we can (want to) be 100% consistent . Even If I
really like to see every attribute to be with or without @ (because
consistency). I do not think it will be perfect. For eg. one of things I
like about D is how easy I can switch from PHP, Java C# or C++. Even
rewrite some of my code from PHP consist with following steps:
1.) remove $
2.) replace :: and -> for .
3.) some minor changes (sometimes nothing)

So I would prefer if private, public, protected, final, static stay
without @,
but D specific things like
pure,immutable,nothrow,nogc,safe,trust,disable,deprecated... would go
with @

if I speak about immutable(const) I only mean function attribut not storage. And It would be perfect if all theese must be on the right side:

// OK
public final void someFunc() @immutable @safe @nogc @nothrow
{
}

// OK
public final immutable(int) someFunc() @immutable @safe @nogc @nothrow
{
    return 5
}

// Deprecated
public final immutable int someFunc() @immutable @safe @nogc @nothrow
{
    return 5
}

// Error or Deprecated
public final @immutable int someFunc() @safe @nogc @nothrow
{
    return 5
}

On Tuesday, 27 January 2015 at 21:15:16 UTC, Daniel Kozak wrote:
> Jonathan M Davis via Digitalmars-d píše v Út 27. 01. 2015 v 08:49 -0800:
>> On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:
>> > On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
>> > > You're right. I forgot about those two. But it's still the case that the
>> > > number of function attributes that don't have @ on them is_far_  greater
>> > > than the number of those that do.
>> >
>> > But I explained that most function attributes don't only apply to
>> > functions but to variables as well:
>> >
>> > public, protected, package, private, static, const,
>> > immutable, inout, and deprecated
>> >
>> > So it can be consistent that the above don't use @.
>> >
>> > These only affect functions, not variables, so should be @attributes IMO:
>> >
>> > final, override, abstract
>> >
>> > These affect both:
>> >
>> > return, ref
>> >
>> > So if we want some kind of consistency, we can achieve it by adding @
>> > for final, override, abstract, and removing it for 'return'.
>> 
>> abstract also applies to classes, as does final. Also, if we end up adding
>> any new attributes later, they're bound to have @ on them to avoid requiring
>> a keyword (which is why we have @ on some of them in the first place), and
>> if the new attribute applies to variables or types as well, then the
>> division that you're suggesting falls apart.
>> 
>> IMHO, if we have to search for a way to make them consistent, then there's
>> no point. We're just going to end up with making things more consistent in
>> one way and less in another without necessarily making it any easier for
>> anyone to keep track of, so we'd just be shuffling things around. I think
>> that there needs to be a clear and solid benefit to changing which
>> attributes have @ and which don't, or we shouldn't mess with them.
>
> Exactly I do not think we can (want to) be 100% consistent . Even If I
> really like to see every attribute to be with or without @ (because
> consistency). I do not think it will be perfect. For eg. one of things I
> like about D is how easy I can switch from PHP, Java C# or C++. Even
> rewrite some of my code from PHP consist with following steps:
> 1.) remove $
> 2.) replace :: and -> for .
> 3.) some minor changes (sometimes nothing)
>
> So I would prefer if private, public, protected, final, static stay
> without @,
> but D specific things like
> pure,immutable,nothrow,nogc,safe,trust,disable,deprecated... would go
> with @
>
> if I speak about immutable(const) I only mean function attribut not
> storage. And It would be perfect if all theese must be on the right
> side:
>
> // OK
> public final void someFunc() @immutable @safe @nogc @nothrow
> {
> }
>
> // OK
> public final immutable(int) someFunc() @immutable @safe @nogc @nothrow
> {
>     return 5
> }
>
> // Deprecated
> public final immutable int someFunc() @immutable @safe @nogc @nothrow
> {
>     return 5
> }
>
> // Error or Deprecated
> public final @immutable int someFunc() @safe @nogc @nothrow
> {
>     return 5
> }

Good idea.  The only think I would change is when an attribute appears on the right side, why not omit the '@' symbol :)  Other then that I like the consistency of putting the attributes in the same place.  But even if you kept the '@' symbol I would still prefer your proposal over what we have now.  It's more consistent and no longer looks weird.  When someone new comes along it makes sense and doesn't look like a hack.

On Tuesday, 27 January 2015 at 18:21:37 UTC, Nick Treleaven wrote:
>> I think you may have missed the point.  I believe what Jonathan is
>> saying is that if you turn abstract into @abstract then you have to
>> consider how to solve the "abstract class" issue.  Do you change it to:
>>
>> @abstract class ?
>
> Yes, because it affects the class's functions, not its variable members.

Probably unimportant, but no, abstract and final apply to classes, not to members.
tl;dr what's problem with applying attributes to classes? Classes can have various attributes, abstract and final are just among them. I would recommend this formatting:
---
@abstract @final @notypeinfo
class ...
---

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.

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.

The word "obvious" is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-)

Bye,
bearophile

On Wednesday, 28 January 2015 at 13:14:16 UTC, 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.
>
> The word "obvious" is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-)

I am aware of Python Zen and generally it is not applicable to D. Multiple ways of doing the same thing can be justified both for backwards compatibility and pragmatical reason. But in this case I see no improvement that could justify it.

I'd welcome the change to attribute syntax but only one that actually fixes the problems and not just rearranges things.

On Wednesday, 28 January 2015 at 13:14:16 UTC, bearophile wrote:
> The word "obvious" is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-)

Yes... but which one is obvious:

[0.1*x for x in range(10)]

map(operator.mul,range(10),[0.1]*10)

numpy.arange(0.,0.95,0.1)

numpy.linspace(0,0.9,num=10)

list(itertools.islice(itertools.count(0.0, 0.1), 10))

...

Ola Fosheim Grøstad:

> [0.1*x for x in range(10)]
>
> map(operator.mul,range(10),[0.1]*10)
>
> numpy.arange(0.,0.95,0.1)
>
> numpy.linspace(0,0.9,num=10)
>
> list(itertools.islice(itertools.count(0.0, 0.1), 10))

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 :-)

Bye,
bearophile