> import std.stdio;
>
> @safe int safe()
> {
> 	auto i = 8;
> 	return i;
> }
>
> void main(string ars[])
> {
> 	writeln(safe);
> 	
> }
> ---------------------------
>
> What you want is just impossible...

Would be a good use case for dfix. It really isn't hard to rename every identifier consistently.

On Monday, 23 June 2014 at 22:02:26 UTC, Tobias Pankrath wrote:
>> import std.stdio;
>>
>> @safe int safe()
>> {
>> 	auto i = 8;
>> 	return i;
>> }
>>
>> void main(string ars[])
>> {
>> 	writeln(safe);
>> 	
>> }
>> ---------------------------
>>
>> What you want is just impossible...
>
> Would be a good use case for dfix. It really isn't hard to rename every identifier consistently.

Maybe the future will tell you you're right...
From my point of view this change is a very unprobable one but who knows ?
^^

People are skeptikal about the the air-skate too...
I don't wanna be segregative...

On Monday, 23 June 2014 at 22:02:26 UTC, Tobias Pankrath wrote:
>> import std.stdio;
>>
>> @safe int safe()
>> {
>> 	auto i = 8;
>> 	return i;
>> }
>>
>> void main(string ars[])
>> {
>> 	writeln(safe);
>> 	
>> }
>> ---------------------------
>>
>> What you want is just impossible...
>
> Would be a good use case for dfix. It really isn't hard to rename every identifier consistently.

Yep, perfect place to start experimenting with a Dfix and see what kind of language cleanup it would afford.

For those who don't know what we're talking about:

http://blog.golang.org/introducing-gofix

Andrei seems enthusiastic:

http://forum.dlang.org/thread/lmmdej$2j94$1@digitalmars.com#post-lncpdr:242ufh:241:40digitalmars.com

On Monday, 23 June 2014 at 22:16:22 UTC, Grogan wrote:
> On Monday, 23 June 2014 at 22:02:26 UTC, Tobias Pankrath wrote:
>>> import std.stdio;
>>>
>>> @safe int safe()
>>> {
>>> 	auto i = 8;
>>> 	return i;
>>> }
>>>
>>> void main(string ars[])
>>> {
>>> 	writeln(safe);
>>> 	
>>> }
>>> ---------------------------
>>>
>>> What you want is just impossible...
>>
>> Would be a good use case for dfix. It really isn't hard to rename every identifier consistently.
>
> Maybe the future will tell you you're right...
> From my point of view this change is a very unprobable one but who knows ?
> ^^
>
> People are skeptikal about the the air-skate too...
> I don't wanna be segregative...

I meant the 'hoverboard' of course...

BTW I think '@' makes sense. And another BTW: in your fantastic nazi plan which consists into eradicating the '@' prefix, how would look the UDA ?
I mean that '@' has a signification in the D grammar not only for predifined attributes, but also for user ones...

since D has Attribute lists e.g. @("string", 7, foo, bar)

make them work with build-in attributes or convert build-in
attributes to UDA's, then you can use them as single attributes
or with attribute lists

struct pure;
struct safe;
struct nothrow;
...

@pure @safe @nothrow
or
@(pure, safe, nothrow)

On Tuesday, 24 June 2014 at 12:46:10 UTC, AG wrote:
> since D has Attribute lists e.g. @("string", 7, foo, bar)
>
> make them work with build-in attributes or convert build-in
> attributes to UDA's, then you can use them as single attributes
> or with attribute lists
>
> struct pure;
> struct safe;
> struct nothrow;
> ...
>
> @pure @safe @nothrow
> or
> @(pure, safe, nothrow)

Hmm, didn't know you could do that with UDAs, certainly looks better than this:

https://github.com/D-Programming-Language/phobos/blob/master/std/math.d#L385

Maybe we should add another @nogc just to make sure. ;) That line's going to look even worse if DIP 64 goes through and more @s are added.

On 2014-06-23 22:34, Jonathan M Davis via Digitalmars-d wrote:

> It would be very cool if we could remove @ from all of the built-in
> attributes, but the whole reason that they have them in the first place is
> because it was decided that we didn't want to add new keywords - and that was
> several years ago when D had a smaller user base. So, I really don't see it
> changing at this point. If anything, we might go the _other_ way and add @
> onto the attributes that don't have it in order to make them more consistent
> (though I hope that we don't do that, because it's ugly and more verbose).

Since we got UDA's that use the @attribute syntax, the idea of appending an @ symbol in front of an attribute to avoid name collisions doesn't work anymore.

From a user point of view, the attributes starting with an @ symbol are just as much keywords as those who don't.

> I sympathize with you, but I think that we're stuck at this point.

I we want to minimize name collisions it would be better to remove all attributes and only have a single attribute, like this:

@attribute(nothrow, public, const) void foo ();

-- 
/Jacob Carlborg

On 24.06.2014 21:32, Jacob Carlborg wrote:
> Since we got UDA's that use the @attribute syntax, the idea of appending
> an @ symbol in front of an attribute to avoid name collisions doesn't
> work anymore.
>
>  From a user point of view, the attributes starting with an @ symbol are
> just as much keywords as those who don't.

Wouldn't an attribute like @nogc only be a keyword for attribute symbols, while something like nothrow is a keyword for everything?

E.g. using @nogc means I can't define my own "nogc" UDA but I can have a function or variable named nogc, while I can't have a function named "nogc". Being a "attribute keyword" seems a much smaller restriction on user code.
>
>> I sympathize with you, but I think that we're stuck at this point.
>
> I we want to minimize name collisions it would be better to remove all
> attributes and only have a single attribute, like this:
>
> @attribute(nothrow, public, const) void foo ();
>

If what I wrote above is correct, why not declare existing compiler-attributes "attribute keywords", and then allow a mix of them:


@(nothrow, public, const, "my_custom_attribute") void foo ();

On 2014-06-25 01:32, Marco Nembrini wrote:

> Wouldn't an attribute like @nogc only be a keyword for attribute
> symbols, while something like nothrow is a keyword for everything?

I guess that's true.

> E.g. using @nogc means I can't define my own "nogc" UDA but I can have a
> function or variable named nogc, while I can't have a function named
> "nogc". Being a "attribute keyword" seems a much smaller restriction on
> user code.

I guess so.

> If what I wrote above is correct, why not declare existing
> compiler-attributes "attribute keywords", and then allow a mix of them:
>
>
> @(nothrow, public, const, "my_custom_attribute") void foo ();

Yeah, if the built-in attributes were implemented as UDA's, defined in object.d, then there would be less of a problem. Then one could always use fully qualified symbol names to disambiguate the attributes.

-- 
/Jacob Carlborg

Jacob Carlborg:

> Yeah, if the built-in attributes were implemented as UDA's, defined in object.d, then there would be less of a problem. Then one could always use fully qualified symbol names to disambiguate the attributes.

Walter in the @nogc pull request has explained why this is a bad idea, and I agree with him.

There are many things that need to be fixed in D, like the problem of uniqueness. The problem of attributes like @nogc being names @nogc or nogc is very low on the list. So I suggest to refocus the discussions on more significant things, like tuples, significant missing part of Phobos, etc.

Bye,
bearophile