Re: FAQ for newbies who see pure @safe nothrow @nogc
On 29/01/2015 17:51, Jonathan Marler wrote: Nick I'm putting together the FAQ right now. I don't quite understand this proposal. Could you outline it for me? I'd like to know exactly what words would require an '@' symbol. What is the criteria for when to use an '@' and when not to use one? This current rule is (use '@' if it is not a keyword)...so what would the new rule be? Thanks. My idea was just: if it can apply to variables, use keyword or __keyword. If it doesn't apply to variables, use @attribute. But this shouldn't be documented anywhere.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 16:13:59 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 16:02:44 UTC, matovitch wrote:
On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create
identifier with the same name why aren't they used
everywhere ? By the way, the denomination makes sense too :
function attibutes are either built-in or user defined
attributes. But const can be a qualifier or a
function/method attribute that is two very different
things...maybe not beeing able to use const as a function
attribute but @const would make more sense ?
The purpose of this thread wasn't to re-discuss what was
already discussed. The answer to your idea can be found in
the other thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like @safe and
@nogc and some don't like pure and nothrow.
So one idea is to require an '@' symbol in front of all of
them for the sake of consistency. The problem with this idea
is that you've now introduced inconsistency somewhere else.
Every keyword that you put an '@' symbol in front of, will be
used somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of
these types of inconsistencies. In addition, you've made the
rule of when to use the '@' symbol more complex. Before it
was, Use '@' if it is not a keyword. Now it's, Use '@' if
it is not a keyword except when it's a function attribute.
This definition will likely be made worse since people will
want to solve the newly introduced inconsistencies. So the
new definition will become, Use '@' if it is a keyword
except if it's a function attribute or a class specifier.
By the time you solve every inconsistency you'll have made
every usage of every keyword use the '@' symbol. Then the
rule will be Always use the '@' symbol.
This will definitely be included on the FAQ :) I'll reword
it and modify it but I agree that people will want an
explanation for this.
One can argue that it's hard to remember what is a keyword
(especially in D where there are many) and easier to
distinguish beetween qualifiers and attributes. But I
understand legacy code is an issue and I agree that the FAQ
should just state the facts.
This doesn't really have to do with Legacy code. You can
always support both ways for a time and deprecate the old way.
It appears my answer did not address your idea well enough.
I'll have to put together a better explanation. In the mean
time, could you help me by giving me the gritty details of your
idea. I know others will also want an explanation for this so
I'd like to include one in the FAQ so as to prevent us from
explaining the same thing over and over. You idea was to put
'@' on words if they are attributes and to omit them on
qualifiers. Could you list what words are qualifiers and what
words are attributes? I don't think this idea would work but
hey, maybe you'll prove me wrong, I'll admit I haven't gone
through the details of what problems this idea would create.
Sorry this may be my fault. I think there were only 4 qualifier
in D : const, immutable, share and inout (I am not aware of this
new scope thing). pure is a function attribute and a keyword,
this is inconsistant with other built-in attributes with @ in
front of them like @property or @nogc. I think (and my opinion
doesn't worth much as I am not experienced as a programmer and I
didnt used D very much) that it would be more consistant if we
hadn't this keyword and be forced to use @pure instead. (const
can be a method annotation/attribute too, so should be @const
keeping const as a variable/parameter qualifier).
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 04:16:30 UTC, Jesse Phillips wrote: It would be somewhere under: http://wiki.dlang.org/ Maybe Documentation = Language Design Explanation? Anyone else for or against this? If no one protests I can create it, along with the FAQ from matovich and including Walters extra explanation about increasing redundancy.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 10:43:37 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:38:46 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ? 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. JM Davis Ok ! I'm not sure I understand your question. Why don't we make all the function attributes attributes? Is this what you mean? Why don't we require an '@' symbol before all function attributes?
Re: FAQ for newbies who see pure @safe nothrow @nogc
On 29/01/2015 15:54, Jonathan Marler wrote:
Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these types of
inconsistencies. In addition, you've made the rule of when to use the
'@' symbol more complex. Before it was, Use '@' if it is not a
keyword. Now it's, Use '@' if it is not a keyword except when it's a
function attribute. This definition will likely be made worse since
people will want to solve the newly introduced inconsistencies. So the
new definition will become, Use '@' if it is a keyword except if it's a
function attribute or a class specifier. By the time you solve every
inconsistency you'll have made every usage of every keyword use the '@'
symbol. Then the rule will be Always use the '@' symbol.
No, the idea proposed was:
@safe @override const func();
@abstract class C{}
const var = 5;
__gshared gvar = 4;
const is never @const. @abstract is always @abstract. It is variables
that don't use @attribute syntax. This is not something I invented, it
follows on from existing uses of @attributes and __keywords already
supported by dmd.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ?
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 10:38:46 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ? 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. JM Davis Ok !
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes?
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 17:32:30 UTC, Nick Treleaven
wrote:
No, the idea proposed was:
@safe @override const func();
@abstract class C{}
const var = 5;
__gshared gvar = 4;
const is never @const. @abstract is always @abstract. It is
variables that don't use @attribute syntax. This is not
something I invented, it follows on from existing uses of
@attributes and __keywords already supported by dmd.
Nick I'm putting together the FAQ right now. I don't quite
understand this proposal. Could you outline it for me? I'd like
to know exactly what words would require an '@' symbol. What is
the criteria for when to use an '@' and when not to use one?
This current rule is (use '@' if it is not a keyword)...so what
would the new rule be? Thanks.
Re: FAQ for newbies who see pure @safe nothrow @nogc
About the lists Qualifiers : const (can be an method attribute), immutable (can be an method attribute), inout, shared, (scope ?) Attributes : const (can be a type qualifier), immutable (can be a type qualifier), final (even so I don't understand why private final is so special), pure, @nothrow, @property, @nogc,... Neither qualifier nor attributes : abstract, override,... and many others Why override is not a method attribute...because if you remove it you've change the semantic of the code...final doesn't change anything if you remove it. To me, a function/method attribute enforce a behaviour on the function but you should be able to remove it without changing the semantic.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 17:50:23 UTC, matovitch wrote: About the lists Qualifiers : const (can be an method attribute), immutable (can be an method attribute), inout, shared, (scope ?) Attributes : const (can be a type qualifier), immutable (can be a type qualifier), final (even so I don't understand why private final is so special), pure, @nothrow, @property, @nogc,... Neither qualifier nor attributes : abstract, override,... and many others Why override is not a method attribute...because if you remove it you've change the semantic of the code...final doesn't change anything if you remove it. To me, a function/method attribute enforce a behaviour on the function but you should be able to remove it without changing the semantic. I'll need a better definition of what a qualifier/attribute is. It's ok to use words like qualifier and attribute when discussing ideas, but I'm trying to document how this idea would really affect everything so I need a solid definition of what you mean by a qualifier and an attribute. You said an attribute enforces a behavior on the function but you should be able to remove it without changing the semantics. What do you mean by semantics, because under my definition of semantics, removing a function qualifier does change the semantics. Maybe a better definition is, removing it doesn't change the logic of the function? Not sure. Maybe you can come up with a better definition. Thanks.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 17:51:06 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 17:32:30 UTC, Nick Treleaven
wrote:
No, the idea proposed was:
@safe @override const func();
@abstract class C{}
const var = 5;
__gshared gvar = 4;
const is never @const. @abstract is always @abstract. It is
variables that don't use @attribute syntax. This is not
something I invented, it follows on from existing uses of
@attributes and __keywords already supported by dmd.
Nick I'm putting together the FAQ right now. I don't quite
understand this proposal. Could you outline it for me? I'd
like to know exactly what words would require an '@' symbol.
What is the criteria for when to use an '@' and when not to use
one? This current rule is (use '@' if it is not a
keyword)...so what would the new rule be? Thanks.
Does it really matter ? Please put your first post in there and
be done with it. These proposal are not gonna happen anyway (the
ROI is simply not there).
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 15:10:12 UTC, Jonathan Marler wrote: On Thursday, 29 January 2015 at 10:43:37 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:38:46 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ? 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. JM Davis Ok ! I'm not sure I understand your question. Why don't we make all the function attributes attributes? Is this what you mean? Why don't we require an '@' symbol before all function attributes? Yes, if @ttributes are better because you can create identifier with the same name why aren't they used everywhere ? By the way, the denomination makes sense too : function attibutes are either built-in or user defined attributes. But const can be a qualifier or a function/method attribute that is two very different things...maybe not beeing able to use const as a function attribute but @const would make more sense ?
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create
identifier with the same name why aren't they used everywhere
? By the way, the denomination makes sense too : function
attibutes are either built-in or user defined attributes. But
const can be a qualifier or a function/method attribute that
is two very different things...maybe not beeing able to use
const as a function attribute but @const would make more sense
?
The purpose of this thread wasn't to re-discuss what was
already discussed. The answer to your idea can be found in the
other thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like @safe and
@nogc and some don't like pure and nothrow.
So one idea is to require an '@' symbol in front of all of them
for the sake of consistency. The problem with this idea is
that you've now introduced inconsistency somewhere else. Every
keyword that you put an '@' symbol in front of, will be used
somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these
types of inconsistencies. In addition, you've made the rule of
when to use the '@' symbol more complex. Before it was, Use
'@' if it is not a keyword. Now it's, Use '@' if it is not a
keyword except when it's a function attribute. This
definition will likely be made worse since people will want to
solve the newly introduced inconsistencies. So the new
definition will become, Use '@' if it is a keyword except if
it's a function attribute or a class specifier. By the time
you solve every inconsistency you'll have made every usage of
every keyword use the '@' symbol. Then the rule will be
Always use the '@' symbol.
This will definitely be included on the FAQ :) I'll reword it
and modify it but I agree that people will want an explanation
for this.
One can argue that it's hard to remember what is a keyword
(especially in D where there are many) and easier to distinguish
beetween qualifiers and attributes. But I understand legacy code
is an issue and I agree that the FAQ should just state the facts.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create identifier
with the same name why aren't they used everywhere ? By the
way, the denomination makes sense too : function attibutes are
either built-in or user defined attributes. But const can be a
qualifier or a function/method attribute that is two very
different things...maybe not beeing able to use const as a
function attribute but @const would make more sense ?
The purpose of this thread wasn't to re-discuss what was already
discussed. The answer to your idea can be found in the other
thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like @safe and @nogc
and some don't like pure and nothrow.
So one idea is to require an '@' symbol in front of all of them
for the sake of consistency. The problem with this idea is that
you've now introduced inconsistency somewhere else. Every
keyword that you put an '@' symbol in front of, will be used
somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these
types of inconsistencies. In addition, you've made the rule of
when to use the '@' symbol more complex. Before it was, Use '@'
if it is not a keyword. Now it's, Use '@' if it is not a
keyword except when it's a function attribute. This definition
will likely be made worse since people will want to solve the
newly introduced inconsistencies. So the new definition will
become, Use '@' if it is a keyword except if it's a function
attribute or a class specifier. By the time you solve every
inconsistency you'll have made every usage of every keyword use
the '@' symbol. Then the rule will be Always use the '@'
symbol.
This will definitely be included on the FAQ :) I'll reword it
and modify it but I agree that people will want an explanation
for this.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On 1/29/15 7:03 AM, Jonathan Marler wrote: On Thursday, 29 January 2015 at 04:16:30 UTC, Jesse Phillips wrote: It would be somewhere under: http://wiki.dlang.org/ Maybe Documentation = Language Design Explanation? Anyone else for or against this? If no one protests I can create it, along with the FAQ from matovich and including Walters extra explanation about increasing redundancy. Just do it. -- Andrei
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 16:02:44 UTC, matovitch wrote:
On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create
identifier with the same name why aren't they used everywhere
? By the way, the denomination makes sense too : function
attibutes are either built-in or user defined attributes. But
const can be a qualifier or a function/method attribute that
is two very different things...maybe not beeing able to use
const as a function attribute but @const would make more
sense ?
The purpose of this thread wasn't to re-discuss what was
already discussed. The answer to your idea can be found in
the other thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like @safe and
@nogc and some don't like pure and nothrow.
So one idea is to require an '@' symbol in front of all of
them for the sake of consistency. The problem with this idea
is that you've now introduced inconsistency somewhere else.
Every keyword that you put an '@' symbol in front of, will be
used somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these
types of inconsistencies. In addition, you've made the rule of
when to use the '@' symbol more complex. Before it was, Use
'@' if it is not a keyword. Now it's, Use '@' if it is not
a keyword except when it's a function attribute. This
definition will likely be made worse since people will want to
solve the newly introduced inconsistencies. So the new
definition will become, Use '@' if it is a keyword except if
it's a function attribute or a class specifier. By the time
you solve every inconsistency you'll have made every usage of
every keyword use the '@' symbol. Then the rule will be
Always use the '@' symbol.
This will definitely be included on the FAQ :) I'll reword it
and modify it but I agree that people will want an explanation
for this.
One can argue that it's hard to remember what is a keyword
(especially in D where there are many) and easier to
distinguish beetween qualifiers and attributes. But I
understand legacy code is an issue and I agree that the FAQ
should just state the facts.
This doesn't really have to do with Legacy code. You can always
support both ways for a time and deprecate the old way. It
appears my answer did not address your idea well enough. I'll
have to put together a better explanation. In the mean time,
could you help me by giving me the gritty details of your idea.
I know others will also want an explanation for this so I'd like
to include one in the FAQ so as to prevent us from explaining the
same thing over and over. You idea was to put '@' on words if
they are attributes and to omit them on qualifiers. Could you
list what words are qualifiers and what words are attributes? I
don't think this idea would work but hey, maybe you'll prove me
wrong, I'll admit I haven't gone through the details of what
problems this idea would create.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 18:38:33 UTC, deadalnix wrote: Does it really matter ? Please put your first post in there and be done with it. These proposal are not gonna happen anyway (the ROI is simply not there). Post is up. I agree with you that the ROI is not there, however, if someone doesn't understand why then it's good to help them understand. It produces better developers and helps bring the D community together to have a common understanding. In an ideal world with infinite time we could answer everyone's questions with great detail and walk them through all their concerns and ideas. However, since time is a finite resource, I think having a wiki we can point people to is a great compromise. I saw this suggestion in the thread by multiple people and I think it would help to address it in the wiki. This attitude of thinking that addressing people's concerns doesn't matter is a bit harsh and hurts the language. I've seen that many upper developers share this attitude and it pushes people away from wanting to contribute.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 19:02:22 UTC, Jonathan Marler wrote: On Thursday, 29 January 2015 at 18:38:33 UTC, deadalnix wrote: Does it really matter ? Please put your first post in there and be done with it. These proposal are not gonna happen anyway (the ROI is simply not there). Post is up. I agree with you that the ROI is not there, however, if someone doesn't understand why then it's good to help them understand. It produces better developers and helps bring the D community together to have a common understanding. In an ideal world with infinite time we could answer everyone's questions with great detail and walk them through all their concerns and ideas. However, since time is a finite resource, I think having a wiki we can point people to is a great compromise. I saw this suggestion in the thread by multiple people and I think it would help to address it in the wiki. This attitude of thinking that addressing people's concerns doesn't matter is a bit harsh and hurts the language. I've seen that many upper developers share this attitude and it pushes people away from wanting to contribute. I like *your* attitude ;) I am reading http://dlang.org/attribute.html and realizing how subtle this can be...indeed, the distinction of qualifier vs attributes is fuzzy in my head even, qualifiers are defined to be attributes in the spec...Attribute is a node of the grammar in fact so the def is really accurate but I think with more thinking one could think of something more consistent than it has @ because this is a keyword because the next question will be then why isn't this a keyword because that is a keyword...etc. Write the FAQ a wiki can always be improved.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 19:02:22 UTC, Jonathan Marler wrote: This attitude of thinking that addressing people's concerns doesn't matter is a bit harsh and hurts the language. I've seen that many upper developers share this attitude and it pushes people away from wanting to contribute. It is not what I meant. i think your post address theses concerns very well without needing to get into various proposal in details. Thank for posting it up.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 19:57:49 UTC, matovitch wrote: On Thursday, 29 January 2015 at 19:02:22 UTC, Jonathan Marler wrote: On Thursday, 29 January 2015 at 18:38:33 UTC, deadalnix wrote: Does it really matter ? Please put your first post in there and be done with it. These proposal are not gonna happen anyway (the ROI is simply not there). Post is up. I agree with you that the ROI is not there, however, if someone doesn't understand why then it's good to help them understand. It produces better developers and helps bring the D community together to have a common understanding. In an ideal world with infinite time we could answer everyone's questions with great detail and walk them through all their concerns and ideas. However, since time is a finite resource, I think having a wiki we can point people to is a great compromise. I saw this suggestion in the thread by multiple people and I think it would help to address it in the wiki. This attitude of thinking that addressing people's concerns doesn't matter is a bit harsh and hurts the language. I've seen that many upper developers share this attitude and it pushes people away from wanting to contribute. I like *your* attitude ;) I am reading http://dlang.org/attribute.html and realizing how subtle this can be...indeed, the distinction of qualifier vs attributes is fuzzy in my head even, qualifiers are defined to be attributes in the spec...Attribute is a node of the grammar in fact so the def is really accurate but I think with more thinking one could think of something more consistent than it has @ because this is a keyword because the next question will be then why isn't this a keyword because that is a keyword...etc. Write the FAQ a wiki can always be improved. You wrote it ! This looks great ! :)
FAQ for newbies who see pure @safe nothrow @nogc
I believe we have reached consensus in our discussion about how to solve the issues of having some function attributes use a '@' and some not. void foo() pure @safe nothrow @nogc; I'd like to put the following question/answers somewhere that we can point newbies to so that when someone asks again, the discussion can be quenched immediately by simply directing them to the FAQ. Maybe that means we link them to this post, maybe it means we add it to the site somewhere. Feel free to improve. Here they are: Why do some function attributes have a '@' and some dont? --- Simple answer, Words that are considered keywords don't require a '@', and non-keywords do. A list of keywords is found here http://dlang.org/lex.html#Keyword. This includes pure and nothrow, but does not include safe or nogc. Why don't we make all the function attributes keywords? --- A keyword cannot be an identifier. Since 'int' is a keyword, it cannot be used as a variable name, function name, etc. Because of this, if you add a new keyword, any code that was using that keyword before is now broken. As D matures more keywords may be added but we are also trying to figure out the best set of function attributes. Instead of adding and removing keywords all the time, we use the '@' symbol until it becomes clear the new word should be a keyword. Why do we have to use a '@' if the word is not a keyword? --- It's possible to allow words to be function attributes that are not keywords, however, the D leadership feels that having a word serve as a function attribute in one context and an identifier in another is bad.
Re: FAQ for newbies who see pure @safe nothrow @nogc
It would be somewhere under: http://wiki.dlang.org/ Maybe Documentation = Language Design Explanation?
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 04:16:30 UTC, Jesse Phillips wrote: It would be somewhere under: http://wiki.dlang.org/ Maybe Documentation = Language Design Explanation? Yes, that is a clear sum up of the discussion.
