www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Too many attributes?

reply "Janice Caron" <caron800 googlemail.com> writes:
On 25/04/2008, Yigal Chripun <yigal100 gmail.com> wrote:
  D2 will allow the following:
  pure invariant invariant(int) func(invariant(int)) nothrow;
  Am I the only one that thinks the above is too much?

You're not the only one. Just for the record though, invariant(int) will implicitly cast to and from int, so the above could be simiplified to pure invariant int func(int) nothrow; However, the following cannot be simplified pure invariant invariant(C) func(invariant(C) c) nothrow; where C is a class. And it gets worse. Consider the following code: pure int func(invariant(C) a, invariant(C) b) { if (c == b) ... Whoops! That won't compile, because - guess what!? - opEquals isn't pure!!!! And it doesn't stop there - opEquals cannot be made pure just by changing its declaration, because a pure function must have invariant arguments, and opEquals has to work with or without invariant data. The upshot is that, eventually, Object.opEquals may have to be implemented twice: class Object { // the normal version const bool opEquals(const Object o) {...} // the pure version pure invariant bool opEquals(invariant Object o) {...} } and, therefore, so will anything that overloads it. And then there are delegates. I have mentioned in a previous thread (called something like "big hole in const system") that big problems exist because attributes can be applied to functions /but not to delegates/. That is, we cannot declare pure invariant invariant(C) delegate(invariant(C) c) nothrow dg; If we take the address of func, where func is declared as pure invariant invariant(C) func(invariant(C) c) nothrow; then &func will have type invariant(C) delegate(invariant(C)) That is, all the attributes will have been lost. That makes it possible to break any contract implied by the attributes without the compiler noticing, /just by taking the address of a function/. And then we come to templates. Oh my! These new attributes are going to cause a big problem for templates. Consider: ReturnType!(f) foo(alias f)(ParameterTypeTuple!(f) n) { return f(n); } or should that be... ReturnType!(f) foo(alias f)(ParameterTypeTuple!(f) n) nothrow { return f(n); } ? Hmm. Looks like the real answer is template foo(alias f) { if(is(f == nothrow)) { ReturnType!(f) foo(ParameterTypeTuple!(f) n) nothrow { return f(n); } } else { ReturnType!(f) foo(ParameterTypeTuple!(f) n) { return f(n); } } } (and even that's assuming that we will be able to test for "if(is(f == nothrow))", which also is not certain). In fact, really, the template should also test for "pure" as well, so it can attach the "pure" attribute if it can. And just in case anyone thinks that was a contrived example, real world uses would include root-solving by Newton's method, root-solving by the secant method, numerical integration, etc. - all of which will be pure iff f is pure, nothrow iff f is nothrow, etc. While I understand the reasons for "pure", etc. (- and don't misunderstand me, they are sound reasons!), there are implications for syntax which will come back and bite us if we're not careful. At the very least, I would suggest (1) attributes for delegates (2) attribute tuples for templates (e.g. AttributeTuple!(f) ReturnType!(f) foo(alias f)(ParameterTypeTuple!(f) n) { return f(n); } )
Apr 25 2008
next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Janice Caron wrote:
 While I understand the reasons for "pure", etc. (- and don't
 misunderstand me, they are sound reasons!), there are implications for
 syntax which will come back and bite us if we're not careful. At the
 very least, I would suggest
 
 (1) attributes for delegates
 (2) attribute tuples for templates
 
 (e.g.
 
     AttributeTuple!(f) ReturnType!(f) foo(alias f)(ParameterTypeTuple!(f) n)
     {
         return f(n);
     }
 
 )

My example was a contrived one, but you provided good examples that illustrates the syntactic issues that arise from all those additions to D's syntax. One note regarding your template example: I don't see how that AttributeTuple!(f) helps. this should be solved via introspection at runtime or via traits at compile type. either way, it should be possible to get f's attributes in a tuple/array. something like: f.attributesof which would return a tuple of attributes. since I'm advocating for introduction of user defined attributes to D, I'd suggest that the compiler should treat "const"/"pure" and such as built-in attributes that are provided by the language, so that if you define: [myAttr1, myAttr2] pure int func(invariant C c); then func.attributesof would contain the tuple: (pure, myAttr1, myAttr2). just like a type tuple can contain both built-in types and user defined ones. --Yigal
Apr 25 2008
prev sibling next sibling parent Christian Kamm <kamm.incasoftware shift-at-left-and-remove-this.de> writes:
 And then there are delegates. I have mentioned in a previous thread
 (called something like "big hole in const system") that big problems
 exist because attributes can be applied to functions /but not to
 delegates/. That is, we cannot declare
 
         pure invariant invariant(C) delegate(invariant(C) c) nothrow dg;

For what it's worth, the D spec 2.013 allows delegates to have the pure and nothrow attributes. (Declarations: BasicType2 and Expressions: FunctionLiteral) Christian
Apr 25 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 25/04/2008, Christian Kamm
<kamm.incasoftware shift-at-left-and-remove-this.de> > > For what it's
worth, the D spec 2.013 allows delegates to have the pure and
 nothrow attributes. (Declarations: BasicType2 and Expressions:
 FunctionLiteral)

Ooh nice! Thanks for pointing that out. But they need to be able to take const and invariant attributes too. (And come to think of it, if you allowed delegates to be declared static then we could lose the "function" keyword altogether, as "delegate static" could take over that role. Maybe that's pushing things too far though).
Apr 25 2008
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Janice Caron wrote:
 On 25/04/2008, Yigal Chripun <yigal100 gmail.com> wrote:
  D2 will allow the following:
  pure invariant invariant(int) func(invariant(int)) nothrow;
  Am I the only one that thinks the above is too much?

You're not the only one.

I second that.
 
     pure int func(invariant(C) a, invariant(C) b)
     {
         if (c == b) ...
 
 Whoops! That won't compile, because - guess what!? - opEquals isn't pure!!!!
 
 And it doesn't stop there - opEquals cannot be made pure just by
 changing its declaration, because a pure function must have invariant
 arguments, and opEquals has to work with or without invariant data.
 The upshot is that, eventually, Object.opEquals may have to be
 implemented twice:
 
     class Object
     {
         // the normal version
         const bool opEquals(const Object o) {...}
 
         // the pure version
         pure invariant bool opEquals(invariant Object o) {...}
     }
 
 and, therefore, so will anything that overloads it.
 

Another example why "scoped const", despite "only" being a syntactical convenience, might be so important. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 29 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Janice Caron wrote:
 On 29/04/2008, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:
 Another example why "scoped const", despite "only" being a syntactical
 convenience, might be so important.

That wouldn't help in this case. The reason you need the second declaration is so that one declaration can be pure, the other not. Steven's proposal solves a different problem.

Not if you combine "scoped const" with the partially pure function rules (see new thread). Example: //(using 'anyconst' as the scoped const keyword) class Object { pure anyconst bool opEquals(anyconst(Object) obj) {...} The 3 versions of opEquals would be created. 2 of them would partially pure, the other (the invariant one) would be fully pure. The mutable version would be redudant though. This would work, but since there is redundancy, I'm thinking there could be a better way to do it. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 29 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 29/04/2008, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:
 Another example why "scoped const", despite "only" being a syntactical
 convenience, might be so important.

That wouldn't help in this case. The reason you need the second declaration is so that one declaration can be pure, the other not. Steven's proposal solves a different problem.
Apr 29 2008