www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Optional tags and attributes

reply "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
Hopefully, now I'm posting to the right place (instead of 
.announce like last time >_<).

Is there a way to make function tags and attributes optional? For 
example, C++ has noexcept tag that takes an optional bool that 
actually enables or desables the whole specifier. I find its uses 
in C++ somewhat painful due to clumsy template syntax, but the 
value is there.

I found a discussion from 2010 about doing something similar in 
D, but it doesn't seem to have went far, and I don't know if 
anything has been done in this direction.



In essence, here's what I mean:

import std.traits;

template isNoThrow(alias func) {
   enum bool isNoThrow = (functionAttributes!func & nothrow_) != 0;
}

void thisIsSoPolymorphic(T)(T t) nothrow(isNoThrow!(T.unsure)) {
   // ...
   t.unsure();
   // ...
}

Without this behavior, I basically have to either drop nothrow 
entirely (bummer), or make two functions enclosed in static if 
checks, which obviously blows up if I want to make more tags 
optional.
Jan 17 2014
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
Templates automatically infer their attributes based on the 
input, so you don't have to specify them there.

If you do a foo!(nothrow_function)(), foo is also nothrow 
(unless, of course, it throws!)
Jan 17 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-01-18 04:02, Steven Schveighoffer wrote:

 I think a "use the attributes of X" would be a general enough tool.

 Something like:

   void thisIsSoPolymorphic() attrOf(T.foo)

Yet another case for AST macros: class Careful (T) { void thisIsSoPolymporphic () inferAttributes(T.foo) { } } macro inferAttributes (Context context, Ast!(Symbol) symbol, Declaration decl) { foreach (attr ; symbol.attributes) decl.attributes ~= attr; return decl; } -- /Jacob Carlborg
Jan 18 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/18/2014 03:50 AM, Stanislav Blinov wrote:

Oh, I see now where it went the wrong way. From my own example, of course :) Surely I was meaning: class Careful(T) { //... void thisIsSoPolymorphic() nothrow(isNoThrow!(T.foo)) { ... } //... } Something to that extent. So that yes, the function itself is not a template.

Well, but it will be annotated nothrow anyway if possible. Inference is not actually limited in the implied way. In case you _really_ want to be explicit about this (and you seem not to), the general problem precluding a nice library implementation is that built-in attributes cannot be aliased. You can always use a string mixin though: mixin(`void thisIsSoPolymorphic()`~(isNoThrow!(T.foo)?:"nothrow":"")~q{{ ... }}); This easily scales to all attributes you may find interesting: mixin(`void thisIsSoPolymorphic()`~stringOfAttributes!(T.foo)~q{{ ... }});
Jan 18 2014
prev sibling next sibling parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Saturday, 18 January 2014 at 00:23:14 UTC, Adam D. Ruppe wrote:
 Templates automatically infer their attributes based on the 
 input, so you don't have to specify them there.

 If you do a foo!(nothrow_function)(), foo is also nothrow 
 (unless, of course, it throws!)

This doesn't apply here. I'm not using function as a template paramter. That's the whole case here. Suppose I'm writing a template class that's parametrized by some type, and in my method I want to call methods of that type. I cannot make any of my functions nothrow until I am sure the methods I call will not throw, and the compiler will tell me. And how can I be sure they don't throw if it's an arbitrary type? I can check it, sure, with that isNoThrow() template. But how then to use that information in my own function declaration?
Jan 17 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Saturday, 18 January 2014 at 00:32:53 UTC, Stanislav Blinov 
wrote:
 On Saturday, 18 January 2014 at 00:23:14 UTC, Adam D. Ruppe 
 wrote:
 Templates automatically infer their attributes based on the 
 input, so you don't have to specify them there.

 If you do a foo!(nothrow_function)(), foo is also nothrow 
 (unless, of course, it throws!)

This doesn't apply here. I'm not using function as a template paramter. That's the whole case here. Suppose I'm writing a template class that's parametrized by some type, and in my method I want to call methods of that type. I cannot make any of my functions nothrow until I am sure the methods I call will not throw, and the compiler will tell me. And how can I be sure they don't throw if it's an arbitrary type? I can check it, sure, with that isNoThrow() template. But how then to use that information in my own function declaration?

Perhaps using template if statements and pure functions. A little like how I implemented some of Dvorm's[0] utility functions. That way it can execute at compile time. You can pass the type to it and check any method you would call if its nothrow or not via traits. That way you can have two declarations but with one being opposite of the if. [0] https://github.com/rikkimax/Dvorm/blob/master/src/orm/util.d#L31
Jan 17 2014
prev sibling next sibling parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Saturday, 18 January 2014 at 00:42:35 UTC, Rikki Cattermole 
wrote:
 Perhaps using template if statements and pure functions. A 
 little like how I implemented some of Dvorm's[0] utility 
 functions. That way it can execute at compile time. You can 
 pass the type to it and check any method you would call if its 
 nothrow or not via traits.

Obviously I didn't explain myself clearly. I know how to determine if a function is nothrow or pure or safe or anything else thanks to D's awesomeness :) But what I want is a way to *use* that knowledge when declaring my own functions. Or rather, tell the compiler "Wait, I really want this to be nothrow, but I don't know if that function will throw. Here's a check for you, please make me nothrow if it passes". After all, tags are not just for enforcing correctness at compile time, they can be used (once verified) for optimization too. So it'd be nice to find a way to provide all the nice info to the compiler whenever possible. It's not just about nothrow, but also pure, safe/ system/ trusted, hell, even public/protected/private for that matter. :)
 That way you can have two declarations but with one being 
 opposite of the if.

...Or four in case I'd also want pure/not pure, or nine if I'd also want safe/not safe...
Jan 17 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Saturday, 18 January 2014 at 00:57:27 UTC, Stanislav Blinov 
wrote:
 Obviously I didn't explain myself clearly. I know how to 
 determine if a function is nothrow or pure or  safe or anything 
 else thanks to D's awesomeness :) But what I want is a way to 
 *use* that knowledge when declaring my own functions. Or 
 rather, tell the compiler "Wait, I really want this to be 
 nothrow, but I don't know if that function will throw. Here's a 
 check for you, please make me nothrow if it passes". After all, 
 tags are not just for enforcing correctness at compile time, 
 they can be used (once verified) for optimization too. So it'd 
 be nice to find a way to provide all the nice info to the 
 compiler whenever possible. It's not just about nothrow, but 
 also pure,  safe/ system/ trusted, hell, even 
 public/protected/private for that matter. :)

 That way you can have two declarations but with one being 
 opposite of the if.

...Or four in case I'd also want pure/not pure, or nine if I'd also want safe/not safe...

Okay, I'll explain what I was inferring. If the methods your calling are lets say nothrow which can be checked by a pure function lets say. Using the template if statement we can check that it does throw. For example: void myfunc(T)(T arg) nothrow if (checkIfNothrow!T) {} void myfunc(T)(T arg) if (checkIfNoModifiers!T) {} void myfunc(T)(T arg) pure if (checkIfPure!T) {} Basically you have to define all combinations. That is what I was meaning. Preferably you'll use q{} your code that is actually used. And use a template mixin to generate all these statements, so you don't have to!
Jan 17 2014
prev sibling next sibling parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Saturday, 18 January 2014 at 01:52:56 UTC, Rikki Cattermole 
wrote:

 Okay, I'll explain what I was inferring. If the methods your 
 calling are lets say nothrow which can be checked by a pure 
 function lets say. Using the template if statement we can check 
 that it does throw.

I'm going to continue to think that I am overly not explicit and thus there continues to be a misunderstanding. However, I'd like to correct that misunderstanding by saying that *I KNOW HOW TO DO THIS WITH TEMPLATES AND STATIC IF* :D (By the way, I did sort of mention it in the first post). In other words, I wasn't asking *how* to do it in principle, I'm interested if there's any possibility to do it elegantly.
 For example:
 void myfunc(T)(T arg) nothrow if (checkIfNothrow!T) {}
 void myfunc(T)(T arg) if (checkIfNoModifiers!T) {}
 void myfunc(T)(T arg) pure if (checkIfPure!T) {}

 Basically you have to define all combinations. That is what I 
 was meaning.
 Preferably you'll use q{} your code that is actually used. And 
 use a template mixin to generate all these statements, so you 
 don't have to!

That is precisely the thing I'd like to avoid entirely. Following your example (which is not entirely correct since in this case I won't be checking T, I'll be checking T.foo or T.bar or whatever combination of those :o), I'd have to have three distinct function definitions, even though in the end only one of them will ever be compiled into my class. Yes, this can be simplified by mixing-in the actual function body into all of those definitions. But we have to be able to do better :) I'm not trying to say that C++'s syntax wins, no. The syntax can be anything, other than blowing up my class with all those declarations and ifs :). If we're talking templates, it would sure be nice to be just a tad more generic. Consider: void myfunc(T)(T arg) pure(isPure!(T.foo)) nothrow(isNoThrow!(T.bar)) { ... } I know that myfunc *can* be pure (I wrote it) and it *won't* throw anywhere, and that would be true for all the function body, *except* I also know that T.foo *may* be impure or T.bar *may* throw (because I didn't write them, T is an arbitrary type possibly from user code). Because of those "may"s I either have to drop the tags entirely, or to have four different declarations with various combinations of constraints. Having the ability to specify the condition for a tag would elegantly solve this issue. It's one definition, no static ifs or additional template constraints. Again, the syntax here could be anything, like something proposed in that discussion I mentioned earlier: void myfunc(T)(T arg) optional(isPure!(T.foo), pure) optional(isNoThrow!(T.bar), nothrow) { ... } or anything else. Granted, presence of overloads and templates may make those ifPure/ifNoThrow/ifWhatever checks not that trivial to implement or invoke, but still possible nevertheless.
Jan 17 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Jan 18, 2014 at 01:52:55AM +0000, Rikki Cattermole wrote:
 On Saturday, 18 January 2014 at 00:57:27 UTC, Stanislav Blinov
 wrote:
Obviously I didn't explain myself clearly. I know how to determine
if a function is nothrow or pure or  safe or anything else thanks
to D's awesomeness :) But what I want is a way to *use* that
knowledge when declaring my own functions. Or rather, tell the
compiler "Wait, I really want this to be nothrow, but I don't know
if that function will throw. Here's a check for you, please make
me nothrow if it passes". After all, tags are not just for
enforcing correctness at compile time, they can be used (once
verified) for optimization too. So it'd be nice to find a way to
provide all the nice info to the compiler whenever possible. It's
not just about nothrow, but also pure,  safe/ system/ trusted,
hell, even public/protected/private for that matter. :)

That way you can have two declarations but with one being
opposite of the if.

...Or four in case I'd also want pure/not pure, or nine if I'd also want safe/not safe...

Okay, I'll explain what I was inferring. If the methods your calling are lets say nothrow which can be checked by a pure function lets say. Using the template if statement we can check that it does throw. For example: void myfunc(T)(T arg) nothrow if (checkIfNothrow!T) {} void myfunc(T)(T arg) if (checkIfNoModifiers!T) {} void myfunc(T)(T arg) pure if (checkIfPure!T) {} Basically you have to define all combinations. That is what I was meaning. Preferably you'll use q{} your code that is actually used. And use a template mixin to generate all these statements, so you don't have to!

What's wrong with just letting the compiler infer the maximal function attributes? void fun(T)(T arg) if (is(typeof(arg.method()))) { arg.method(); } int globvar; struct Impure { void method() safe nothrow { globvar++; } } struct Thrower { void method() pure safe { throw new Exception("abc"); } } struct Unsafe { void method() pure nothrow { int[2] arr; int* ptr = arr.ptr; ptr++; *ptr = 123; } } pragma(msg, typeof(fun!Impure)); pragma(msg, typeof(fun!Thrower)); pragma(msg, typeof(fun!Unsafe)); Compiler output: nothrow safe void(Impure arg) pure safe void(Thrower arg) pure nothrow system void(Unsafe arg) Notice how the best attributes have been inferred for fun(), depending on what type was passed in, even though we never annotated fun() with any attributes. That is, fun()'s attributes change depending on how T.method() was implemented. So if T.method happens to be pure, safe, and nothrow, then so will fun(). If fun() calls multiple methods, then its final attributes will be the intersection of the attributes of all the method calls plus its own code (so if you threw in fun(), then it would become nothrow regardless of whether T.method is nothrow or not, but if fun() itself never throws, then it will be marked nothrow depending on whether T.method throws). Sadly, this only works for template functions currently -- so I still had to annotate the various method()'s by hand, but if you were to turn them into template functions too, their attributes will also be inferred automatically. T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Jan 17 2014
prev sibling next sibling parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Saturday, 18 January 2014 at 02:38:28 UTC, H. S. Teoh wrote:

 What's wrong with just letting the compiler infer the maximal 
 function
 attributes?

...
 Sadly, this only works for template functions currently -- so I 
 still
 had to annotate the various method()'s by hand, but if you were 
 to turn
 them into template functions too, their attributes will also be 
 inferred
 automatically.

Oh, I see now where it went the wrong way. From my own example, of course :) Surely I was meaning: class Careful(T) { //... void thisIsSoPolymorphic() nothrow(isNoThrow!(T.foo)) { ... } //... } Something to that extent. So that yes, the function itself is not a template.
Jan 17 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 17 Jan 2014 21:50:07 -0500, Stanislav Blinov  
<stanislav.blinov gmail.com> wrote:

 On Saturday, 18 January 2014 at 02:38:28 UTC, H. S. Teoh wrote:

 What's wrong with just letting the compiler infer the maximal function
 attributes?

...
 Sadly, this only works for template functions currently -- so I still
 had to annotate the various method()'s by hand, but if you were to turn
 them into template functions too, their attributes will also be inferred
 automatically.

Oh, I see now where it went the wrong way. From my own example, of course :) Surely I was meaning: class Careful(T) { //... void thisIsSoPolymorphic() nothrow(isNoThrow!(T.foo)) { ... } //... } Something to that extent. So that yes, the function itself is not a template.

I was about to respond with a similar point, but it seems you are understanding now how the nothrow inference works :) I can't think of a correct way to do this without repeating code, since it has to be polymorphic (and therefore not a template), nothrow inference only works on templates. The idea to be able to attach attributes/annotations based on compile-time introspection would be a worthy addition to the language IMO, but I really don't like the syntax you have outlined (I see you don't like it either). Especially if you have to do all the attributes this way. I think a "use the attributes of X" would be a general enough tool. Something like: void thisIsSoPolymorphic() attrOf(T.foo) -Steve
Jan 17 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 17, 2014 at 10:02:44PM -0500, Steven Schveighoffer wrote:
 On Fri, 17 Jan 2014 21:50:07 -0500, Stanislav Blinov
 <stanislav.blinov gmail.com> wrote:
 
On Saturday, 18 January 2014 at 02:38:28 UTC, H. S. Teoh wrote:

What's wrong with just letting the compiler infer the maximal function
attributes?

...
Sadly, this only works for template functions currently -- so I still
had to annotate the various method()'s by hand, but if you were to turn
them into template functions too, their attributes will also be inferred
automatically.

Oh, I see now where it went the wrong way. From my own example, of course :) Surely I was meaning: class Careful(T) { //... void thisIsSoPolymorphic() nothrow(isNoThrow!(T.foo)) { ... } //... } Something to that extent. So that yes, the function itself is not a template.

I was about to respond with a similar point, but it seems you are understanding now how the nothrow inference works :) I can't think of a correct way to do this without repeating code, since it has to be polymorphic (and therefore not a template), nothrow inference only works on templates.

See https://d.puremagic.com/issues/show_bug.cgi?id=10329 and the associated pull, which has just been merged. I haven't tested it myself yet, but it would appear that methods inside template classes should now have their methods' attributes inferred too? If so, then you can just take out the nothrow clause and it should work? (But since I haven't tested this yet I could be wrong.)
 The idea to be able to attach attributes/annotations based on
 compile-time introspection would be a worthy addition to the
 language IMO, but I really don't like the syntax you have outlined
 (I see you don't like it either). Especially if you have to do all
 the attributes this way.
 
 I think a "use the attributes of X" would be a general enough tool.
 
 Something like:
 
  void thisIsSoPolymorphic() attrOf(T.foo)

Hmm. Would functionAttributes and SetFunctionAttributes in std.traits help somehow? Not sure how you might actually use them to declare methods with desired attributes, though. But maybe there's a way. T -- Always remember that you are unique. Just like everybody else. -- despair.com
Jan 17 2014
prev sibling next sibling parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Saturday, 18 January 2014 at 03:02:45 UTC, Steven 
Schveighoffer wrote:

 I was about to respond with a similar point, but it seems you 
 are understanding now how the nothrow inference works :)

O:)
 I can't think of a correct way to do this without repeating 
 code, since it has to be polymorphic (and therefore not a 
 template), nothrow inference only works on templates.

 The idea to be able to attach attributes/annotations based on 
 compile-time introspection would be a worthy addition to the 
 language IMO, but I really don't like the syntax you have 
 outlined (I see you don't like it either).

No, I actually quite like that C++ syntax, although AFAIK it's only "special" in that one particular occasion. I was mentioning that syntax doesn't matter because I wanted to make sure I'm not pushing any C++ features here, just making a point about a nice usability feature :)
 Especially if you have to do all the attributes this way.

 I think a "use the attributes of X" would be a general enough 
 tool.

 Something like:

  void thisIsSoPolymorphic() attrOf(T.foo)

And here is where I would disagree. Fine-grained control over each attribute is more important. For example, the function may be always nothrow (say I handle all the exceptions in the world or assert(0) on what's left; D helpfully doesn't consider assert(0) as throwing :) ), but it may be conditionally pure or safe.
Jan 17 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 17 Jan 2014 22:21:15 -0500, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:

 On Fri, Jan 17, 2014 at 10:02:44PM -0500, Steven Schveighoffer wrote:
 On Fri, 17 Jan 2014 21:50:07 -0500, Stanislav Blinov
 <stanislav.blinov gmail.com> wrote:

On Saturday, 18 January 2014 at 02:38:28 UTC, H. S. Teoh wrote:

What's wrong with just letting the compiler infer the maximal function
attributes?

...
Sadly, this only works for template functions currently -- so I still
had to annotate the various method()'s by hand, but if you were to  


them into template functions too, their attributes will also be  


automatically.

Oh, I see now where it went the wrong way. From my own example, of course :) Surely I was meaning: class Careful(T) { //... void thisIsSoPolymorphic() nothrow(isNoThrow!(T.foo)) { ... } //... } Something to that extent. So that yes, the function itself is not a template.

I was about to respond with a similar point, but it seems you are understanding now how the nothrow inference works :) I can't think of a correct way to do this without repeating code, since it has to be polymorphic (and therefore not a template), nothrow inference only works on templates.

See https://d.puremagic.com/issues/show_bug.cgi?id=10329 and the associated pull, which has just been merged. I haven't tested it myself yet, but it would appear that methods inside template classes should now have their methods' attributes inferred too?

Hm... how does that work on a virtual function? You may not know the body. It does seem like a good solution for most cases.
 The idea to be able to attach attributes/annotations based on
 compile-time introspection would be a worthy addition to the
 language IMO, but I really don't like the syntax you have outlined
 (I see you don't like it either). Especially if you have to do all
 the attributes this way.

 I think a "use the attributes of X" would be a general enough tool.

 Something like:

  void thisIsSoPolymorphic() attrOf(T.foo)

Hmm. Would functionAttributes and SetFunctionAttributes in std.traits help somehow? Not sure how you might actually use them to declare methods with desired attributes, though. But maybe there's a way.

Not sure, it looks like SetFunctionAttributes only can be used to construct types, not declare functions. -Steve
Jan 17 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 17 Jan 2014 22:25:11 -0500, Stanislav Blinov  
<stanislav.blinov gmail.com> wrote:

 On Saturday, 18 January 2014 at 03:02:45 UTC, Steven Schveighoffer wrote:

 I think a "use the attributes of X" would be a general enough tool.

 Something like:

  void thisIsSoPolymorphic() attrOf(T.foo)

And here is where I would disagree. Fine-grained control over each attribute is more important. For example, the function may be always nothrow (say I handle all the exceptions in the world or assert(0) on what's left; D helpfully doesn't consider assert(0) as throwing :) ), but it may be conditionally pure or safe.

void thisIsSoPolymorphic() attrOf(T.foo) nothrow I would assume, we could come up with ways to mask out attributes you want to set specifically. For example if you always want it NOT to be nothrow, you could do something like: void thisIsSoPolymorphic() attrOf(withoutNothrow!(T.foo)) -Steve
Jan 17 2014
prev sibling parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Saturday, 18 January 2014 at 03:22:43 UTC, H. S. Teoh wrote:
 On Fri, Jan 17, 2014 at 10:02:44PM -0500, Steven Schveighoffer 
 wrote:

 See https://d.puremagic.com/issues/show_bug.cgi?id=10329

 If so, then you can just take out the nothrow clause and it 
 should work?
 (But since I haven't tested this yet I could be wrong.)

Hmm... It certainly *looks* that way, but I don't have a local pull of the compiler, so can't test either. But if it's true, that's great!
 Hmm. Would functionAttributes and SetFunctionAttributes in 
 std.traits
 help somehow? Not sure how you might actually use them to 
 declare
 methods with desired attributes, though. But maybe there's a 
 way.

functionAttributes can be used for inference (see isNoThrow in my first post). But alas, currently attributes can't be mixed-in or otherwise conditionally specified (without resorting to static if), at least I don't know one, what prompted me to start this topic in the first place.
Jan 17 2014