www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A rationale for pure nothrow ---> pure nothrow (and nothing else

reply Don <nospam nospam.com> writes:
We'll need compile-time reflection for all attributes. This can lead us 
to a rationale for which attributes are keywords, and which are  attributes.

For   attributes, we can have a syntax vaguely like:
__traits(hasAttribute, "safe", foo);
The details aren't important, but it seems clear that we'll need some 
such thing.

Anything which isn't an   attribute will need to have its own traits 
support. We want to minimize the number of such special cases.

Here are some rules.

* If it exists as a keyword in C++, it is not an  attribute.
* hasAttribute is never used for identifying conditional compilation.
* If accessing it via a standard hasAttribute syntax will reduce the 
number of reflection special cases, it should have an   prefix.

Note that some attributes, though not keywords in C++, are intimately 
tied to other features which are C++ keywords. So the combination of 
rule 1 + rule 3 stops them from being   attributes.

I know these rules are a little ad-hoc, and aren't as unambiguous as we 
might hope, but I think they do give us the consequences that we want. 
Importantly, it lets  property continue as an attribute.

---
Specific keywords which have been mentioned in the past:

private, protected, public:
No. Keywords in C++.
package:
No. Tied to the other protection classes. Once the others are out, we 
don't benefit from hasAttribute syntax for the last survivor.

deprecated:
No. This is equivalent to version(deprecated), but with better error 
messages. Not an attribute.

virtual:
No. keyword in C++.
override:
No. Tied to virtual.

safe, trusted, system:
Yes.

property:
Yes. We can avoid a reflection special case.

pure, nothrow:
Yes. These should change.
Feb 24 2010
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:
 We'll need compile-time reflection for all attributes. This can lead us 
 to a rationale for which attributes are keywords, and which are 
  attributes.
 
 For   attributes, we can have a syntax vaguely like:
 __traits(hasAttribute, "safe", foo);
 The details aren't important, but it seems clear that we'll need some 
 such thing.
 
 Anything which isn't an   attribute will need to have its own traits 
 support. We want to minimize the number of such special cases.
 
 Here are some rules.
 
 * If it exists as a keyword in C++, it is not an  attribute.
 * hasAttribute is never used for identifying conditional compilation.
 * If accessing it via a standard hasAttribute syntax will reduce the 
 number of reflection special cases, it should have an   prefix.
 
 Note that some attributes, though not keywords in C++, are intimately 
 tied to other features which are C++ keywords. So the combination of 
 rule 1 + rule 3 stops them from being   attributes.
 
 I know these rules are a little ad-hoc, and aren't as unambiguous as we 
 might hope, but I think they do give us the consequences that we want. 
 Importantly, it lets  property continue as an attribute.
 
 ---
 Specific keywords which have been mentioned in the past:
 
 private, protected, public:
 No. Keywords in C++.
 package:
 No. Tied to the other protection classes. Once the others are out, we 
 don't benefit from hasAttribute syntax for the last survivor.
 
 deprecated:
 No. This is equivalent to version(deprecated), but with better error 
 messages. Not an attribute.
 
 virtual:
 No. keyword in C++.
 override:
 No. Tied to virtual.
 
 safe, trusted, system:
 Yes.
 
 property:
 Yes. We can avoid a reflection special case.
 
 pure, nothrow:
 Yes. These should change.

I think this is the best proposal regarding this issue so far. Is there still time to change this? -Lars
Feb 24 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-24 21:32:57 -0500, Don <nospam nospam.com> said:

 We'll need compile-time reflection for all attributes. This can lead us 
 to a rationale for which attributes are keywords, and which are 
  attributes.
 
 For   attributes, we can have a syntax vaguely like:
 __traits(hasAttribute, "safe", foo);
 The details aren't important, but it seems clear that we'll need some 
 such thing.
 
 Anything which isn't an   attribute will need to have its own traits 
 support. We want to minimize the number of such special cases.

Deciding whether something is an attribute or not depending on how it's easier to express them in __traits sounds like a bad idea to me.
 Here are some rules.
 
 * If it exists as a keyword in C++, it is not an  attribute.
 * hasAttribute is never used for identifying conditional compilation.
 * If accessing it via a standard hasAttribute syntax will reduce the 
 number of reflection special cases, it should have an   prefix.

I don't like any of these rules. The language shouldn't be primarily designed to ease reflection, it should be designed to be easy to learn and understand.
 Note that some attributes, though not keywords in C++, are intimately 
 tied to other features which are C++ keywords. So the combination of 
 rule 1 + rule 3 stops them from being   attributes.

That's getting messier and messier. You shouldn't have to know C++ when learning about attributes in D, and even less about what features of D are "intimately tied" to some other feature in C++.
 I know these rules are a little ad-hoc, and aren't as unambiguous as we 
 might hope, but I think they do give us the consequences that we want. 
 Importantly, it lets  property continue as an attribute.

Why is it important that property continues to be an attribute? To me property is the attribute that is farthest to what I expect an attribute to be. To me, an attribute should be seen like this: """ If something is an attribute, then it's accessory to the language. Something is accessory when you can remove it completely from a program and expect the program to compile and behave the same. Attributes are not changing anything beside adding some restrictions to improve safety, optimization, etc. """ This rule is easy to understand and is useful for newbies who then know they can simply ignore attributes in the code they read. Making things ignorable sort of diminish the language complexity while learning. Also, while it limits what can be attributes to accessory things, it doesn't forbid things that could be attributes from being keyword if they're judged important enough to be not accessory.
 private, protected, public:
 No. Keywords in C++.
 package:
 No. Tied to the other protection classes. Once the others are out, we 
 don't benefit from hasAttribute syntax for the last survivor.

These could almost be attributes by my definition(*). But I agree there is a big precedent in many other languages to make them keywords. And you could say visibility protection is important enough and not accessory. (*): The only thing preventing 'private' and 'protected' from being attributes is that they also have the side effect of making functions non-virtual, which is incompatible with my definition of an attribute.
 deprecated:
 No. This is equivalent to version(deprecated), but with better error 
 messages. Not an attribute.

This isn't equivalent to version(deprecated) at all. Deprecated function are still compiled and put in the resulting object, and can be called freely from other deprecated functions and from non-deprecated function when the compiler flag is on. It's more comparable to pure, nothrow, and safe in that it's adding a restriction regarding who can call the function. For instance, make you main() deprecated and it'll be able to call any deprecated function without the compiler flag. :-) I'd tend to make it an attribute.
 virtual:
 No. keyword in C++.
 override:
 No. Tied to virtual.

I think it makes sense for it to be a keyword only if it is mandatory. Otherwise it's just an accessory thing you can discard at will.
 safe, trusted, system:
 Yes.

Fine with me. A program can compile and work fine if you remove all these attributes everywhere, so they're accessory.
 property:
 Yes. We can avoid a reflection special case.

I think this one is the silliest of all attributes. It does change the syntax of the function call, and sometime also the semantic meaning of the name, so it's not accessory at all. You can't discard it and expect things to work fine. So it definitely should not be an attribute.
 pure, nothrow:
 Yes. These should change.

Fine with me. A program can compile and work fine if you remove these two attributes everywhere, so they're accessory (though useful for optimization and other things). -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 25 2010
parent reply Don <nospam nospam.com> writes:
Michel Fortin wrote:
 To me, an attribute should be seen like this:
 
 """
 If something is an attribute, then it's accessory to the language. 
 Something is accessory when you can remove it completely from a program 
 and expect the program to compile and behave the same. Attributes are 
 not changing anything beside adding some restrictions to improve safety, 
 optimization, etc.
 """

Please. *I* invented that rule. It was appealing, but IT DOES NOT WORK. And it has been discussed to death. Forget it. Be aware of the state that the language is in right now. What I've proposed here is a last-ditch effort to improve the situation from 'completely random' with as little change as possible. In previous discussions, the only thing everyone agreed on was that pure should be pure, and nothrow should become nothrow. So I've come up with a rationale which changes those two, and retains the status quo on everything else. And I'm hoping that it's not too late to change those two. Sure, the rationale is weak. But IMHO it's better than nothing, which is what we have now. And we're just about out of time. To rephrase it: the rationale is that if it has a precedent as a keyword in C-family languages, it remains a keyword. If not, it uses syntax. It means that instead of having situations where we say, "this is not an attribute for historical reasons in the development of D", we instead say "this is not an attribute, because of compatibility with C-family languages". The point of bringing reflection into it was as a rationale that closely-related features stay together (eg, package behaves the same as private). You could probably come up with a stronger rationale for the same result. I'm basically saying that if we change pure, nothrow, it is *possible* to come up with an after-the-fact rationale. If we don't, the situation is hopeless. And I don't really care if deprecated is an attribute or not. It's borderline; we probably get a more explainable result if it becomes deprecated. But if pure, nothrow don't become pure, nothrow it's just random.
Feb 25 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-25 14:11:02 -0500, Don <nospam nospam.com> said:

 Michel Fortin wrote:
 To me, an attribute should be seen like this:
 
 """
 If something is an attribute, then it's accessory to the language. 
 Something is accessory when you can remove it completely from a program 
 and expect the program to compile and behave the same. Attributes are 
 not changing anything beside adding some restrictions to improve 
 safety, optimization, etc.
 """

Please. *I* invented that rule.

I did not claim I invented it, just that this is what I think should be an attribute. It's very possible I was influenced by your previous posts into thinking this, but I'm not always tracking perfectly where each of my opinions come from. Sorry if I overexplained everything to you. I quite agree that having pure as pure and nothrow as nothrow would be better than nothing. If you want a rationale that works for everything beside pure and nothrow, I think it'd work better to just say that new keywords added in version 2 of D that behave as attributes(*) use the attribute syntax. If pure and nothrow stay like this, just add a cutoff date to the above. (*): http://www.digitalmars.com/d/2.0/attribute.html I know you're trying to avoid this kind of "historical incident" kind of rule, but making a rule that depends instead on the history of C-derived languages doesn't really improve things in my opinion. Keep in mind that the state of "other C-derived languages" is both vague and moving target; D1 isn't. Also, a rule that depends on compile-time reflection special cases means that you have to explain compile-time reflection to those who ask you what the rule is. Most of the time when explaining to someone you'll choose to say it's arbitrary or historical rather than using a too complex rule. If you're trying to push a rule to simplify the implementation of compile-time reflection, then that's fine. But to me trying to make a rationale that work for property while disregarding history is just like interpolating coordinates from unrelated data sets. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 25 2010
parent reply Don <nospam nospam.com> writes:
Michel Fortin wrote:
 On 2010-02-25 14:11:02 -0500, Don <nospam nospam.com> said:
 
 Michel Fortin wrote:
 To me, an attribute should be seen like this:

 """
 If something is an attribute, then it's accessory to the language. 
 Something is accessory when you can remove it completely from a 
 program and expect the program to compile and behave the same. 
 Attributes are not changing anything beside adding some restrictions 
 to improve safety, optimization, etc.
 """

Please. *I* invented that rule.

I did not claim I invented it, just that this is what I think should be an attribute. It's very possible I was influenced by your previous posts into thinking this, but I'm not always tracking perfectly where each of my opinions come from. Sorry if I overexplained everything to you.

The point is that it's been previously discussed, and it doesn't work.
 I quite agree that having pure as  pure and nothrow as  nothrow would be 
 better than nothing.
 
 If you want a rationale that works for everything beside pure and 
 nothrow, I think it'd work better to just say that new keywords added in 
 version 2 of D that behave as attributes(*) use the  attribute syntax. 

You could say that. It's pretty much the same as the list from 'C-family languages'. we don't care about backwards compatibility with keywords from D1.
 If pure and nothrow stay like this, just add a cutoff date to the above.

That isn't any better than an arbitrary list.
 (*): http://www.digitalmars.com/d/2.0/attribute.html
 
 I know you're trying to avoid this kind of "historical incident" kind of 
 rule, but making a rule that depends instead on the history of C-derived 
 languages doesn't really improve things in my opinion.

No, I'm trying to avoid a "prehistorical accident" type of rule. For these purposes, the history of D begins when TDPL is published. We're still in prehistory for a few more weeks. Compatibility with C and C++ has always been critical for D; D contains many historical accidents from C. But D has not yet set any historical precedents. If we simultaneously release a language with attributes, together with attributes that don't use them, it looks silly.
Feb 25 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-26 01:06:09 -0500, Don <nospam nospam.com> said:

 No, I'm trying to avoid a "prehistorical accident" type of rule.
 
 For these purposes, the history of D begins when TDPL is published. 
 We're still in prehistory for a few more weeks.
 
 Compatibility with C and C++ has always been critical for D; D contains 
 many historical accidents from C. But D has not yet set any historical 
 precedents.

All that's fine.
 If we simultaneously release a language with  attributes, together with 
 attributes that don't use them, it looks silly.

That's true. But I think the rules you proposed at the start of this thread are worse than the "prehistorical accident" explanation. I think both explanations are silly in their own right, but one is much more complex to grasp for no benefit. Principles must be kept simple to be useful. If they're not simple they'll look arbitrary anyway and you'll end up trying to make the arbitrary look rational. I think it's better not to pretend there is a principle rather than saying there is one that looks like an excuse. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 26 2010
prev sibling parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Don wrote:
 To rephrase it: the rationale is that if it has a precedent as a keywor=

 in C-family languages, it remains a keyword. If not, it uses   syntax.

something that exists as an attribute in D? Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Feb 26 2010
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Don, el 25 de febrero a las 03:32 me escribiste:
 We'll need compile-time reflection for all attributes. This can lead
 us to a rationale for which attributes are keywords, and which are
  attributes.
 
 For   attributes, we can have a syntax vaguely like:
 __traits(hasAttribute, "safe", foo);
 The details aren't important, but it seems clear that we'll need
 some such thing.
 
 Anything which isn't an   attribute will need to have its own traits
 support. We want to minimize the number of such special cases.
 
 Here are some rules.
 
 * If it exists as a keyword in C++, it is not an  attribute.
 * hasAttribute is never used for identifying conditional compilation.
 * If accessing it via a standard hasAttribute syntax will reduce the
 number of reflection special cases, it should have an   prefix.
 
 Note that some attributes, though not keywords in C++, are
 intimately tied to other features which are C++ keywords. So the
 combination of rule 1 + rule 3 stops them from being   attributes.
 
 I know these rules are a little ad-hoc, and aren't as unambiguous as
 we might hope, but I think they do give us the consequences that we
 want. Importantly, it lets  property continue as an attribute.

I think this is really silly. Inventing a set of wicked rules just to match an arbitrary decision is really worse than accepting that arbitrary decision per se. Now you have to remember some complicated rules to try to make sense of something that doesn't make sense in the first place. The only rule that makes a little sense for me is 2), but I don't even agree with the deprecated case, deprecated is both version(deprecated) *and* issuing a warning, and gives you information about the function that you might want to know via reflection. If you want safe, trusted, system, property, pure and nothrow as attributes but not private, protected, public, package and deprecated, I think it's better to say that than inventing some weird ad-hoc rules. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------
Feb 26 2010
parent reply Don <nospam nospam.com> writes:
Leandro Lucarella wrote:
 Don, el 25 de febrero a las 03:32 me escribiste:
 We'll need compile-time reflection for all attributes. This can lead
 us to a rationale for which attributes are keywords, and which are
  attributes.

 For   attributes, we can have a syntax vaguely like:
 __traits(hasAttribute, "safe", foo);
 The details aren't important, but it seems clear that we'll need
 some such thing.

 Anything which isn't an   attribute will need to have its own traits
 support. We want to minimize the number of such special cases.

 Here are some rules.

 * If it exists as a keyword in C++, it is not an  attribute.
 * hasAttribute is never used for identifying conditional compilation.
 * If accessing it via a standard hasAttribute syntax will reduce the
 number of reflection special cases, it should have an   prefix.

 Note that some attributes, though not keywords in C++, are
 intimately tied to other features which are C++ keywords. So the
 combination of rule 1 + rule 3 stops them from being   attributes.

 I know these rules are a little ad-hoc, and aren't as unambiguous as
 we might hope, but I think they do give us the consequences that we
 want. Importantly, it lets  property continue as an attribute.

I think this is really silly. Inventing a set of wicked rules just to match an arbitrary decision is really worse than accepting that arbitrary decision per se. Now you have to remember some complicated rules to try to make sense of something that doesn't make sense in the first place. The only rule that makes a little sense for me is 2), but I don't even agree with the deprecated case, deprecated is both version(deprecated) *and* issuing a warning, and gives you information about the function that you might want to know via reflection. If you want safe, trusted, system, property, pure and nothrow as attributes but not private, protected, public, package and deprecated, I think it's better to say that than inventing some weird ad-hoc rules.

I genuinely thought pure, nothrow was a no-brainer. I really thought the explanation that "we made all attibutes use the form, except those where it was prevented by historical precedent" was quite defensible. But I was very, very wrong. Looks like the community is giving a massive vote for complete unpredictability. <Throws hands in air />
Feb 26 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 26/02/10 21:48, Don wrote:
 I genuinely thought  pure,  nothrow was a no-brainer.

 I really thought the explanation that "we made all attibutes use the  
 form, except those where it was prevented by historical precedent" was
 quite defensible.

 But I was very, very wrong. Looks like the community is giving a massive
 vote for complete unpredictability.

 <Throws hands in air />

I don't see why people seem to be against this, pure and nothrow seem to fit right in under what I think of as attributes. Historical reasons seems perfectly valid to me, considering most users will be coming to D from other languages as opposed to learning from scratch. I agree the rules you suggested need a little tweaking before they're there, they're along the right lines though.
Feb 26 2010
parent Robert Clipsham <robert octarineparrot.com> writes:
On 28/02/10 15:40, Leandro Lucarella wrote:
 I'm not against this, I'm against weird ad-hoc rules to justify it =)

[A few years down the road, D2 is more popular, more code is becoming available for it, more programs are being written in it] Novice: There's just one thing I don't understand, why is XXX an attribute and YYY not? Is there any rule for what's an attribute and what isn't? [Situation A] Experienced D User: There's no rule for it, you've just gotta learn which are attributes and which aren't. [Situation B] EDU: Everything you expect to be an attribute is, with a couple of exceptions for historical reasons, such as <list>. [Situation C] EDU: There's a rule for it, you can find it at http://.../, but the general rule is CCCC. ---- If we can come up with some ad-hoc rule, even if it's quite complicated I think it'd be better than nothing. It's too late to sort things out properly at this point, but if we can get some sort of a rule it'd help when deciding what should be an attribute for D3 and what shouldn't. If we leave ourselves without a rule now it's gonna get even harder to come up with even an ad-hoc rule.
Feb 28 2010
prev sibling next sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Don wrote:
 I genuinely thought  pure,  nothrow was a no-brainer.
=20
 I really thought the explanation that "we made all attibutes use the  
 form, except those where it was prevented by historical precedent" was
 quite defensible.
=20
 But I was very, very wrong. Looks like the community is giving a massiv=

 vote for complete unpredictability.
=20
 <Throws hands in air />
=20

several people (including me) contest is the ridiculous pseudo-rationale you've given. "For historical reasons" is a good enough rationale to explain why some attributes (like "private") don't use the syntax while others do. No need to drag C/C++ into this... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Feb 26 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-26 17:48:05 -0500, "Jérôme M. Berger" <jeberger free.fr> said:

 	I didn't see anyone contest  pure or  nothrow in this thread. What
 several people (including me) contest is the ridiculous
 pseudo-rationale you've given. "For historical reasons" is a good
 enough rationale to explain why some attributes (like "private")
 don't use the   syntax while others do. No need to drag C/C++ into
 this...

Same here, not contesting pure or nothrow. I'd prefer to see a rationale based on a simple principle. Creating a few twisted principles to justify what we have now is worse than having none in my opinion. Lets be honest with ourselves and accept that it's like this for historical reasons, and be done with it. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 26 2010
prev sibling next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
On 2/26/2010 14:48, Don wrote:
 I really thought the explanation that "we made all attibutes use the  
 form, except those where it was prevented by historical precedent" was
 quite defensible.

I'd like to see *all* adjectives in the language, including those inherited from other languages, turned into attributes. That would be consistent. Historical precedent is less important to me than a clean language. To deal with the huge body of code that uses e.g. 'public' instead of ' public', the compiler could be modified to accept both forms. Then the non-attribute form could be deprecated and finally removed. -- Rainer Deyke - rainerd eldwood.com
Feb 26 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Don wrote:

 
 I genuinely thought  pure,  nothrow was a no-brainer.
 
 I really thought the explanation that "we made all attibutes use the  
 form, except those where it was prevented by historical precedent" was
 quite defensible.
 
 But I was very, very wrong. Looks like the community is giving a massive
 vote for complete unpredictability.
 
 <Throws hands in air />

Pick what you're going to pick. Personally, I have no problem with historical precedent. Changing public or private to be attributes would be quite disconcerting given how C++, Java, C#, D1, etc. all have them as keywords. And making them attributes would make porting code that much harder. It seems entirely valid to me. However, in the end, they are what they are and we just get to deal with it. Personally, I'd expect attributes to be more reflection-centric (as in potentially checked at runtime, though D's runtime reflection is currently lacking) and keywords to be more compile-time centric. I tend to think of attributes as being addons to the language rather than directly a part of it. So, either they're user-defined (which I don't think we can do in D yet), or they're the kind of thing which would result in giving compiler warnings, or allowing it to do some additional stuff, but aren't really a key part of the language. However, under that rational, I'd probably end up making most of the items currently up for discussion keywords rather than attributes. Regardless of why you choose to make a particular modifier an attribute or a keyword, there are going to be reasons to disagree. I don't think that it's quite as subjective as picking function names, but it's still pretty subjective. So, I don't think that worrying over the reasons for it is going to help much. Personally, I say pick the keywords such that it minimizes how much code will have to change - ported or otherwise. I think that historical reasons is a fine reason for choosing which way to go with a particular word. It's arbitrary enough already, so just minimize how much has to be changed. And when it comes down to it, we'll just have to deal with it however it is. If it's an attribute, we'll use it as an attribute. If it's a keyword, we'll use it as a keyword. In the end, I don't think that it matters all that much when it comes to new code. But at least historical reasons would limit the amount of code that would have to be changed. - Jonathan M Davis
Feb 26 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Changing public or private to be attributes would be 
 quite disconcerting given how C++, Java, C#, D1, etc. all have them as 
 keywords. And making them attributes would make porting code that much 
 harder. It seems entirely valid to me.

I think that making public or private as attributes requires just a textual search & replace of the lowercase string "public" with " public" and the same for private. This change requires a small time even if you don't use an IDE. And IDE can even allow you to avoid to replace those words if they are inside a comment/string. In comparison to this, the recent D2 change of fixed-sized arrays that are now passed by value and not by reference needs in my opinion more care when you translate C code to D. Bye, bearophile
Feb 27 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
bearophile wrote:

 Jonathan M Davis:
 
 Changing public or private to be attributes would be
 quite disconcerting given how C++, Java, C#, D1, etc. all have them as
 keywords. And making them attributes would make porting code that much
 harder. It seems entirely valid to me.

I think that making public or private as attributes requires just a textual search & replace of the lowercase string "public" with " public" and the same for private. This change requires a small time even if you don't use an IDE. And IDE can even allow you to avoid to replace those words if they are inside a comment/string. In comparison to this, the recent D2 change of fixed-sized arrays that are now passed by value and not by reference needs in my opinion more care when you translate C code to D. Bye, bearophile

Oh, it's far worse than that. In C++, public and private are labels. They don't go on each individual function. You'd probably have to parse the code to correctly, automatically manipulate the labels into attributes. And D supports public and private as labels in addition to going on each function, so you'd have the problem with both C++ and D code. What you suggest would work for Java, and I'm pretty sure that it works for C# (it's been a while since I've coded in it though, so I don't recall for certain which way they use public and private), but for C++, D1, and older D2 code, it wouldn't work. So, unless the suggestion is that public and private be allowed as labels, and then when they're used on functions, they're now attributes, then simple text replacement doesn't work. And I really think that leaving them as labels and having them as attributes on functions would make the two uses too different. Besides, I see no gain in making public and private attributes. They're already keywords, if you leave them as labels, they have to remain keywords, so I see no gain in making them attributes. It just makes porting code harder. - Jonathan M Davis
Feb 27 2010
parent reply =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
On 02/27/2010 08:18 PM, Jonathan M Davis wrote:
 Oh, it's far worse than that. In C++, public and private are labels. They
 don't go on each individual function. You'd probably have to parse the code
 to correctly, automatically manipulate the labels into attributes. And D
 supports public and private as labels in addition to going on each function,
 so you'd have the problem with both C++ and D code. What you suggest would
 work for Java, and I'm pretty sure that it works for C# (it's been a while
 since I've coded in it though, so I don't recall for certain which way they
 use public and private), but for C++, D1, and older D2 code, it wouldn't
 work.

 So, unless the suggestion is that public and private be allowed as labels,
 and then when they're used on functions, they're now attributes, then simple
 text replacement doesn't work. And I really think that leaving them as
 labels and having them as attributes on functions would make the two uses
 too different.

 Besides, I see no gain in making public and private attributes. They're
 already keywords, if you leave them as labels, they have to remain keywords,
 so I see no gain in making them attributes. It just makes porting code
 harder.

 - Jonathan M Davis

Is there something wrong with this: class A { private: /* things */ public: /* public things */ } ..? Seeing as the label-like syntax works today for, well, almost anything. Like this: void main(string[] args) { writeln(atoi("12")); } extern (C): int atoi(const(char)* s);
Feb 27 2010
parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Pelle MÃ¥nsson wrote:
 Is there something wrong with this:
 
 class A {
     private:
      /* things */
     public:
      /* public things */
 }
 
 ..?
 
 Seeing as the label-like syntax works today for, well, almost anything.
 Like this:
 
 void main(string[] args) {
      writeln(atoi("12"));
 }
 
 extern (C):
 
      int atoi(const(char)* s);

Regardless of whether that would be a good idea or not, as it stands, attributes have to be on _something_. At the moment, in D, I think that they're restricted to functions. Labels aren't attributes and it makes no sense for them to be. And I don't see anything gained by making them use the same syntax as attributes. public and private are fine as they are. Changing the syntax of public and private labels would just increase porting headaches and increase D's learning curve for people who know C++. - Jonathan M Davis
Feb 27 2010
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Don wrote:
...
 
 I genuinely thought  pure,  nothrow was a no-brainer.
 
 I really thought the explanation that "we made all attibutes use the  
 form, except those where it was prevented by historical precedent" was
 quite defensible.
 
 But I was very, very wrong. Looks like the community is giving a massive
 vote for complete unpredictability.
 
 <Throws hands in air />

Massive? Not everybody in this thread was against these rules and this thread is not even massive (yet?) I like it. Ideally you want to capture the reason why there is some sort consensus here with pure and nothrow. It's just a bit backwards justifying something after the fact and messy, but that's how it is. Better to have a weird rule than no rule imho. This probably also has been talked to death but I can't refrain from asking: when hasAttribute will be implemented, will user defined attributes be considered or are they definitely off the table for D2?
Feb 27 2010
prev sibling next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
 
 I genuinely thought  pure,  nothrow was a no-brainer.
 
 I really thought the explanation that "we made all attibutes use the  
 form, except those where it was prevented by historical precedent" was
 quite defensible.
 
 But I was very, very wrong. Looks like the community is giving a massive
 vote for complete unpredictability.
 
 <Throws hands in air />

I'm with Don - it may not be perfect, but I can understand it. If we go along the other track, we're talking 1-3 months delay. Start thinking like project managers for a little while - yes, a pathological proposition. Once D2 is out, you can go back to business as usual. The alternative is endless procrastination and D being a language that was superseded before it was finalized. Steve
Feb 27 2010
prev sibling next sibling parent reply grauzone <none example.net> writes:
Don wrote:
 We'll need compile-time reflection for all attributes. This can lead us 
 to a rationale for which attributes are keywords, and which are 
  attributes.

Apparently, this attribute syntax makes no sense at all. I suggest we simply remove it and use normal keywords instead.
Feb 27 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
grauzone:
 Apparently, this attribute syntax makes no sense at all. I suggest we 
 simply remove it and use normal keywords instead.

Currently D2 attributes are not necessary, they can be replaced by keywords, but keywords don't scale if you want to define many new attribute-like things, attach them some user-defined semantics, etc. If you have used C#/Java you know some of their usages. So I think D2 attributes are mostly meant for future expansions. Bye, bearophile
Feb 27 2010
parent reply grauzone <none example.net> writes:
bearophile wrote:
 grauzone:
 Apparently, this attribute syntax makes no sense at all. I suggest we 
 simply remove it and use normal keywords instead.

Currently D2 attributes are not necessary, they can be replaced by keywords, but keywords don't scale if you want to define many new attribute-like things, attach them some user-defined semantics, etc. If you have used C#/Java you know some of their usages. So I think D2 attributes are mostly meant for future expansions.

It would be interesting to know whether Walter/Andrei plan to add user defined attributes later. But then, user attributes clashing with compiler defined ones will be the problem. Right now, the attribute syntax seems to be some sort of keyword parking site and/or graveyard.
 Bye,
 bearophile

Feb 27 2010
parent bearophile <bearophileHUGS lycos.com> writes:
grauzone:
 It would be interesting to know whether Walter/Andrei plan to add user 
 defined attributes later.

I hope so :-) The flexibility coming from user defined attributes (that sometimes can be seen a extensions to the type system) is one of the most important purposes of attributes. But they are mostly an additive change compared to the current situation, so they can be added to D3.
 Right now, the attribute syntax seems to be some sort of keyword parking 
 site and/or graveyard.

Right now think of it as another namespace where you can add new keywords, avoiding the risk/annoyance of having a variable with the same name. Bye, bearophile
Feb 27 2010
prev sibling next sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= writes:
I would also tend to agree that this set of rules is a bit arbitrary
and seems a bit like some overfitted classifier in pattern recognition
(although there were worse sets or rules in that regard).

Jugding from the numerous failed, awkward or too specific attempts to
define such a set of rules, maybe it would be better to admit that
there is no clear, boolean rule possible.

Instead we could define a set of measurements against which each
keyword is weighted empirically to choose the optimal form
(attribute/keyword) on a case-by-case basis. Such rules could be for
example:

  - needed changes when porting from C/C++
  - frequency of use -   is quite disrupting, both, in terms of typing
    and reading
  - if it changes the syntax used for accessing the annotated entity it
    probably should not be an attribute (e.g. property or type
    constructors)
  - interference with user code - how likely is it to get name clashes
    with user variable/function names

Obviously there would some disagreement for the third rule - I am
definitely for property as a keyword - but that aside, I think this
approach would prevent us from pretending something which is not there
and also does not lead to possibly silly forced desicions for future
keywords.

Sönke
Feb 28 2010
next sibling parent reply Don <nospam nospam.com> writes:
Sönke Ludwig wrote:
 I would also tend to agree that this set of rules is a bit arbitrary
 and seems a bit like some overfitted classifier in pattern recognition
 (although there were worse sets or rules in that regard).

Almost everyone has missed the point. We are OUT OF TIME. This is just damage control. All that's being discussed here is that it's easier to defend: pure, nothrow, safe than: pure, nothow, safe And I'm arguing that we have a consensus on that. The only other worthwhile question is whether we have a concensus on deprecated. We might. Everything else discussed here has been a complete waste of time. And it may already be too late for pure nothrow.
Feb 28 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-28 10:06:39 -0500, Don <nospam nospam.com> said:

 Sönke Ludwig wrote:
 I would also tend to agree that this set of rules is a bit arbitrary
 and seems a bit like some overfitted classifier in pattern recognition
 (although there were worse sets or rules in that regard).

Almost everyone has missed the point. We are OUT OF TIME. This is just damage control.

There was more than one point in your original argumentation... here are a few ones: 1. We should have a rationale for what is an attribute and what is not. This one I agree. 2. You proposed a rationale: I think your proposed rationale is bad. 3. pure and nothrow should become pure and nothrow. I don't see anyone contesting that. Have I so much missed the point? I know we're sorta out of time. But please understand that damage control by trying to justify the unjustifiable can be worse than the damage itself. I support the proposed changes, but not your proposed overcomplicated rationale for them. If you want a rationale, I think it'd be fine to say that attributes are things you can ignore because they only have a restrictive effect on the semantics (the definition you said you invented). Then mention there is an exception: property.
 The only other worthwhile question is whether we have a concensus on 
  deprecated. We might.

I don't know about others, but I'm for it. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 28 2010
parent reply =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
On 02/28/2010 10:01 PM, Michel Fortin wrote:
 If you want a rationale, I think it'd be fine to say that attributes are
 things you can ignore because they only have a restrictive effect on the
 semantics (the definition you said you invented). Then mention there is
 an exception:  property.

Sorry if I go on and miss the point some more, but I dislike this a lot. That's imposing restrictions on future attributes. Like, for example, memoized. Or something like that. traced, maybe. This is me envisioning user-defined attributes, really. They can reduce boilerplate and increase flexibility in cases like traced.
Feb 28 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-28 18:42:50 -0500, Pelle Månsson <pelle.mansson gmail.com> said:

 On 02/28/2010 10:01 PM, Michel Fortin wrote:
 If you want a rationale, I think it'd be fine to say that attributes are
 things you can ignore because they only have a restrictive effect on the
 semantics (the definition you said you invented). Then mention there is
 an exception:  property.

Sorry if I go on and miss the point some more, but I dislike this a lot. That's imposing restrictions on future attributes. Like, for example, memoized. Or something like that. traced, maybe.

If I'm not mistaken about your intention, making a function memoized wouldn't change its semantics. It'd change how it is optimized, but both from the caller perspective and for the one who write the function's implementation, it's totally transparent. Well, not exactly: it puts some restrictions for the function's body, same as purity I believe. So someone who just want to understand how a program works can ignore memoized when looking at it (at least until he wants to look at the optimizations). The difference with property is that it changes how you call it, it's not a transparent change at all.
 This is me envisioning user-defined  attributes, really. They can 
 reduce boilerplate and increase flexibility in cases like  traced.

Not sure what you mean about traced. If you mean that any call to a function is logged somewhere, then I don't see that as a change in semantics neither for the caller nor for the one who write the function, so it'd have no problem having that as an attribute. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 28 2010
parent reply =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
On 03/01/2010 01:29 AM, Michel Fortin wrote:
 On 2010-02-28 18:42:50 -0500, Pelle Månsson <pelle.mansson gmail.com> said:
 Sorry if I go on and miss the point some more, but I dislike this a
 lot. That's imposing restrictions on future  attributes. Like, for
 example,  memoized. Or something like that.  traced, maybe.

If I'm not mistaken about your intention, making a function memoized wouldn't change its semantics. It'd change how it is optimized, but both from the caller perspective and for the one who write the function's implementation, it's totally transparent. Well, not exactly: it puts some restrictions for the function's body, same as purity I believe. So someone who just want to understand how a program works can ignore memoized when looking at it (at least until he wants to look at the optimizations). The difference with property is that it changes how you call it, it's not a transparent change at all.
 This is me envisioning user-defined  attributes, really. They can
 reduce boilerplate and increase flexibility in cases like  traced.

Not sure what you mean about traced. If you mean that any call to a function is logged somewhere, then I don't see that as a change in semantics neither for the caller nor for the one who write the function, so it'd have no problem having that as an attribute.

I seem to have misunderstood your intentions. I think I am clearer on what you mean now. What about curried? It (potentially) changes the way the function is called, yet looks quite good as an attribute.
Feb 28 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-28 19:46:29 -0500, Pelle Månsson <pelle.mansson gmail.com> said:

 What about  curried? It (potentially) changes the way the function is 
 called, yet looks quite good as an  attribute.

I'm not sure I understand how you expect a curried attribute to be used. How would you call a curried function? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 28 2010
parent =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
On 03/01/2010 04:00 AM, Michel Fortin wrote:
 On 2010-02-28 19:46:29 -0500, Pelle Månsson <pelle.mansson gmail.com> said:

 What about  curried? It (potentially) changes the way the function is
 called, yet looks quite good as an  attribute.

I'm not sure I understand how you expect a curried attribute to be used. How would you call a curried function?

curried pure add(int a, int b) { return a + b; } auto add2 = add(2); assert(add2(2) == 4); assert(add(4, 1) == 5); assert(add(4)(1) == 5); This is how I imagine it. It already exists as a template, somewhere.
Mar 01 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Don wrote:

 Sönke Ludwig wrote:
 I would also tend to agree that this set of rules is a bit arbitrary
 and seems a bit like some overfitted classifier in pattern recognition
 (although there were worse sets or rules in that regard).

Almost everyone has missed the point. We are OUT OF TIME. This is just damage control. All that's being discussed here is that it's easier to defend: pure, nothrow, safe than: pure, nothow, safe And I'm arguing that we have a consensus on that. The only other worthwhile question is whether we have a concensus on deprecated. We might. Everything else discussed here has been a complete waste of time. And it may already be too late for pure nothrow.

I had no problem with your proposed reasoning, and I don't care much all that much if pure, nothrow, or deprecated are attributes or keywords. I'd prefer keywords I think, for pure and nothrow, but I don't care all that much. Just do what you're going to do, and we'll deal with it. Most of the complaints in this thread seem to have to do with your proposed rational rather than your proposal, so it seems to me that you might as well just go with it. Those who will complain will complain, at it will likely have nothing to do with which is what but why, which ultimately doesn't matter all that much. It would be nice if there were a very straightforward rule as to why something is an attribute or a keyword, but what is is, and the biggest difference it would make would be with a newbie learning the language, and I don't think that learning whether a particular word is a keyword or an attribute is going to take much time to learn or be that big a deal overall. - Jonathan M Davis
Feb 28 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 28 Feb 2010 10:06:39 -0500, Don <nospam nospam.com> wrote:

 Sönke Ludwig wrote:
 I would also tend to agree that this set of rules is a bit arbitrary
 and seems a bit like some overfitted classifier in pattern recognition
 (although there were worse sets or rules in that regard).

Almost everyone has missed the point. We are OUT OF TIME. This is just damage control. All that's being discussed here is that it's easier to defend: pure, nothrow, safe than: pure, nothow, safe And I'm arguing that we have a consensus on that.

Fine, then go ahead and make the changes. Why do we need a weird rule to make the changes? Can't we determine a rule later (is that not what we are doing now)? Does the rule need to be in the book? I think just make the changes, and we can determine a rule later, when people start asking about it. BTW, I'm in favor of the change, I couldn't care less about the rule. Arbitrariness is inherent in any language design based on English. I like how word applies to the function without affecting the signature, it's more of a hint to the compiler. The fact that you can't override a function based on pure or nothrow seals the deal for me. -Steve
Mar 01 2010
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Robert Clipsham, el 26 de febrero a las 22:32 me escribiste:
 On 26/02/10 21:48, Don wrote:
I genuinely thought  pure,  nothrow was a no-brainer.

I really thought the explanation that "we made all attibutes use the  
form, except those where it was prevented by historical precedent" was
quite defensible.

But I was very, very wrong. Looks like the community is giving a massive
vote for complete unpredictability.

<Throws hands in air />

I don't see why people seem to be against this, pure and nothrow seem to fit right in under what I think of as attributes. Historical reasons seems perfectly valid to me, considering most users will be coming to D from other languages as opposed to learning from scratch. I agree the rules you suggested need a little tweaking before they're there, they're along the right lines though.

I'm not against this, I'm against weird ad-hoc rules to justify it =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------
Feb 28 2010