Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 20, 2014 DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
http://wiki.dlang.org/DIP64 Attributes in D have two problems: 1. There are too many of them and declarations are getting too verbose 2. New attributes use @ and the old ones do not. I've created a DIP to address these issues. |
June 20, 2014 Re: DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to address these issues.
I like it.
Just thinking aloud, it could be interesting to allow compile time logic of some sort (both on the arguments and on the symbol the attribute is being attached to).
Contrived example borrowing template syntax (which could almost certainly be improved upon):
template @pureIfNameHasPure(Sym) {
static if(__traits(identifier, Sym).canFind("Pure))
alias @pureIfNameHasPure = @pure;
else
alias @pureIfNameHasPure = /* nothing...not sure how to show that */;
}
|
June 20, 2014 Re: DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On Fri, Jun 20, 2014 at 07:22:02PM +0000, Brian Schott via Digitalmars-d wrote: > http://wiki.dlang.org/DIP64 > > Attributes in D have two problems: > 1. There are too many of them and declarations are getting too verbose > 2. New attributes use @ and the old ones do not. > > I've created a DIP to address these issues. And while we're at it, why not also fix holes in attribute semantics on top of just fixing syntax? First, there is no way to mark a function as *impure* as opposed to pure (leaving out "pure" is not an option in template functions due to automatic attribute inference). Also, there's an inconsistency between positive attributes (pure, safe) vs. negative attributes (nothrow, nogc). So ideally, the new syntax should allow you to specify both pure and impure, and ideally, it should not special-case on peculiarities of the English language (pure/impure vs. throw/nothrow). So it should be something like @pure, @!pure, @throw, @!throw, @gc, @!gc, etc., for maximum consistency. I also like your attribute sets idea. This could be the solution we're looking for with transitive attributes (aka inout(pure), inout(nothrow), etc.). If there was some syntax for attribute set intersection, say @a*@b, then we could specify that the attribute set of some given function f() is the intersection of the attribute sets of its input delegates. For example: // This is hypothetical syntax, I'm sure you can think of a // better way to write this. int dgCaller(int delegate(int) @a dg1, int delegate(int) @b dg2) @this = @a*@b // specifies that this function's // attributes is the intersection of @a and @b { if (someCondition) return dg1(1); else return dg2(2); } T -- Heads I win, tails you lose. |
June 20, 2014 Re: DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to address these issues.
Does this work for all attributes? For example:
@OneTo5 = @(1) @(2) @(3) @(4) @(5);
And will this be possible?
struct Test
{
string str;
}
@Tattr(str) = @Test(str);
@Tattr = @Test("");
|
June 20, 2014 Re: DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to address these issues.
They do need standardising but i don't like the idea of attribute sets. Attribute sets would make attributes too over complicated to understand. Attributes need to be simple and concise which i think they already are.
|
June 20, 2014 Re: DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to address these issues.
It may be worth splitting things up a little, or perhaps the extra parts in the DIP are your 'duck.' Because I think normalising every attribute to @ syntax is good. I look at it and think, "Yeah, good." Especially so if it also means that user defined attributes can also be on both sides of a function signature, as that would ease transition between different versions of the language.
I think the parts in the DIP about the exact semantics or syntax for composing attributes will be debated a bit, but the "Let's just put @ in there" part is pretty straightforward.
|
June 20, 2014 Re: DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Friday, 20 June 2014 at 19:48:49 UTC, H. S. Teoh via Digitalmars-d wrote: > First, there is no way to mark a function as *impure* as opposed to pure > (leaving out "pure" is not an option in template functions due to > automatic attribute inference). Also, there's an inconsistency between > positive attributes (pure, safe) vs. negative attributes (nothrow, > nogc). So ideally, the new syntax should allow you to specify both pure > and impure, and ideally, it should not special-case on peculiarities of > the English language (pure/impure vs. throw/nothrow). So it should be > something like @pure, @!pure, @throw, @!throw, @gc, @!gc, etc., for > maximum consistency. I can see this being useful. We'd just have to decide what it means to negate an attribute with arguments. (e.g. `@!name("bob")`) Also in the case of @!throw we'd have to modify the definition of attributes to accept the "throw" token instead of just identifiers. Maybe converting "nothrow" to "@!throws" would be better. > I also like your attribute sets idea. This could be the solution we're > looking for with transitive attributes (aka inout(pure), inout(nothrow), > etc.). If there was some syntax for attribute set intersection, say > @a*@b, then we could specify that the attribute set of some given > function f() is the intersection of the attribute sets of its input > delegates. For example: > > // This is hypothetical syntax, I'm sure you can think of a > // better way to write this. > int dgCaller(int delegate(int) @a dg1, int delegate(int) @b dg2) > @this = @a*@b // specifies that this function's > // attributes is the intersection of @a and @b > { > if (someCondition) > return dg1(1); > else > return dg2(2); > } > > > T Is that use case common enough to justify complicating the compiler? |
June 20, 2014 Re: DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Fri, 20 Jun 2014 15:47:07 -0400, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Fri, Jun 20, 2014 at 07:22:02PM +0000, Brian Schott via Digitalmars-d wrote:
>> http://wiki.dlang.org/DIP64
>>
>> Attributes in D have two problems:
>> 1. There are too many of them and declarations are getting too verbose
>> 2. New attributes use @ and the old ones do not.
>>
>> I've created a DIP to address these issues.
>
> And while we're at it, why not also fix holes in attribute semantics on
> top of just fixing syntax?
>
> First, there is no way to mark a function as *impure* as opposed to pure
> (leaving out "pure" is not an option in template functions due to
> automatic attribute inference). Also, there's an inconsistency between
> positive attributes (pure, safe) vs. negative attributes (nothrow,
> nogc). So ideally, the new syntax should allow you to specify both pure
> and impure, and ideally, it should not special-case on peculiarities of
> the English language (pure/impure vs. throw/nothrow). So it should be
> something like @pure, @!pure, @throw, @!throw, @gc, @!gc, etc., for
> maximum consistency.
I like the idea, but seeing as how attribute sets already take arguments, it's natural to add them to builtins:
@pure(true) == @pure
@pure(false) == not @pure
-Steve
|
June 20, 2014 Re: DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On Fri, 20 Jun 2014 15:22:02 -0400, Brian Schott <briancschott@gmail.com> wrote:
> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to address these issues.
I like it.
At first, I thought "hm.., every project is going to have their own definition for @safe @pure @nothrow," but we can put one in druntime common sets that everyone should use, and we already allow custom attributes anyway that have to be looked up.
One thing this will make slightly more difficult is looking for e.g. @trusted functions, because you can't just grep for them. However, I think with DScanner, you can probably find things easy enough.
2 thoughts:
1. On H.S.Teoh's idea to add negation, what does foo() @pure !@pure mean (or if my preferred syntax was accepted, @pure @pure(false) )?
2. What does this print?
@myattr = @safe @pure;
void foo() @myattr {}
pragma(msg, (&foo).typeof);
-Steve
|
June 20, 2014 Re: DIP64: Attribute Cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On 06/20/2014 09:22 PM, Brian Schott wrote:
> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to address these issues.
Why not make the built-in attributes proper symbols instead and use
alias Seq(T...)=T;
alias spiffy = Seq!(pure,nothrow,safe);
float mul(float a, float b) @spiffy{ }
?
This will also allow use cases such as passing attributes by alias.
|
Copyright © 1999-2021 by the D Language Foundation