Jump to page: 1 26  
Page
Thread overview
DIP64: Attribute Cleanup
Jun 20, 2014
Brian Schott
Jun 20, 2014
Brad Anderson
Jun 20, 2014
H. S. Teoh
Jun 20, 2014
Brian Schott
Jun 20, 2014
Meta
Jun 20, 2014
Gary Willoughby
Jun 20, 2014
w0rp
Jun 20, 2014
Timon Gehr
Jun 21, 2014
Philpax
Jun 22, 2014
Mason McGill
Jun 22, 2014
Jonathan M Davis
Jun 22, 2014
Mason McGill
Jun 22, 2014
Jonathan M Davis
Jun 21, 2014
Kapps
Jun 21, 2014
Peter Alexander
Jun 21, 2014
Brian Rogoff
Jun 21, 2014
Peter Alexander
Jun 21, 2014
Jonathan M Davis
Jun 21, 2014
Brian Schott
Jun 22, 2014
Jonathan M Davis
Jun 22, 2014
Jonathan M Davis
Jun 22, 2014
Paolo Invernizzi
Jun 21, 2014
H. S. Teoh
Jun 21, 2014
Shammah Chancellor
Jun 21, 2014
Temtaime
Jun 21, 2014
Chris Cain
Jun 21, 2014
Chris Cain
Jun 21, 2014
bearophile
Jun 21, 2014
Temtaime
Jun 21, 2014
Chris Cain
Jun 21, 2014
Temtaime
Jun 21, 2014
bearophile
Jun 21, 2014
Artur Skawina
Jun 22, 2014
Shammah Chancellor
Jun 22, 2014
Artur Skawina
Jun 21, 2014
Jonathan M Davis
Jun 22, 2014
Jonathan M Davis
Jun 22, 2014
Artur Skawina
Apr 17, 2016
Anonymous5
Apr 17, 2016
Nick Treleaven
Apr 17, 2016
Nordlöw
Apr 18, 2016
Satoshi
Apr 18, 2016
Basile B.
Apr 18, 2016
Jonathan M Davis
Apr 18, 2016
jmh530
Apr 18, 2016
Jonathan M Davis
Apr 18, 2016
cym13
Apr 18, 2016
Basile B.
Apr 18, 2016
jmh530
Apr 18, 2016
Marco Leise
Apr 19, 2016
Jonathan M Davis
June 20, 2014
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
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
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
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
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
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
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
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
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
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.
« First   ‹ Prev
1 2 3 4 5 6