map kinds of Ranges

[Jonathan M Davis]

On 2011-05-25 14:09, Johann MacDonagh wrote:
> On 5/24/2011 1:51 AM, Jonathan M Davis wrote:
> > On 2011-05-23 22:22, Mehrdad wrote:
> >> On 5/23/2011 10:08 PM, Jonathan M Davis wrote:
> >>> On 2011-05-23 22:02, Mehrdad wrote:
> >>>> One question: Why make the syntax complicated for just a little gain?
> >>>> Wouldn't it kill a lot more birds with one stone if we allow for
> >>>> attributes?
> >>> 
> >>> They _are_ attributes. They're just not user-defined attributes.
> >>> User-defined attributes can still be added later. Besides, the gain is
> >>> _enormous_. Without conditional purity, conditional nothrow,
> >>> conditional @safe, etc. most generic functions (including a large
> >>> portion of Phobos) can never be pure, nothrow, @safe, etc.
> >>> 
> >>> - Jonathan M Davis
> >> 
> >> Wait, what? I never said we shouldn't include conditional stuff, I just
> >> said they should be with @attributes rather than keywords, because that
> >> would somewhat simplify the syntax (fewer keywords, although attribute
> >> syntax is added) and unify things.
> >> 
> >> So the question was: Why not make @pure, etc. become regular metadata?
> >> That way the syntax would likely turn out the same as user-defined
> >> attributes.
> > 
> > The decision was made a while ago to make the attributes which are
> > keywords keywords and the ones which start with @ start with @. It was a
> > bit arbitrary, but the decision was made. Changing it now would break a
> > lot of code for little benefit, and I'd be _very_ surprised if you could
> > talk Walter into it. And it's not like an objective decision can really
> > be made about which start with @ and which don't anyway. Arguments could
> > be made either way for all of them. And honestly, I don't expect that it
> > would be much more complicated (if any more complicated at all) to
> > implement pure(condition) than
> > @pure(condition). I don't think that the compiler treats the keyword
> > attributes and the @ attributes much differently at this point anyway.
> > And even if user-defined attributes were added, I don't think that it
> > would really matter what was done with the keyword attributes and @
> > attributes which are built in. They'd likely be acting differently
> > anyway.
> > 
> > @ vs keyword is one of those things that you stand little chance of
> > getting changed in the language at this point.
> > 
> > - Jonathan M Davis
> 
> So I originally thought that @attributes are purely metadata and are not
> part of the signature of the function, while keywords could
> (potentially) allow the compiler to generate different code. For
> example, pure allows the compiler to squash multiple calls to a pure
> function with the same parameters into a single call.
> 
> However, this maybe isn't the case. I thought this code wouldn't compile:
> 
> import std.stdio;
> import std.conv;
> 
> int test(int function(int x) nothrow myfunc, int y)
> {
> return myfunc(y);
> }
> 
> int test1(int x)
> {
> if (x == 42) throw new Exception("Uh oh!");
> return x + 20;
> }
> 
> nothrow int test2(int x)
> {
> return x / 20;
> }
> 
> void main(string[] argv)
> {
> auto y = to!int(argv[1]);
> writeln(test(&test1, y));
> writeln(test(&test2, y));
> }
> 
> This shouldn't compile (as far as I know), whereas if you replaced the
> "nothrow"s with "@safe"s, it would compile. However, it looks like both
> compile. This looks like a bug. Anyone know off the top of their head if
> this exists in Bugzilla?
> 
> Anyway, from an theoretical point of view, @attributes purely describe a
> symbol, while keywords change it's signature. Perhaps I'm not correct
> though.

Function pointers and delegates don't deal with attributes very well at this 
point. There's at least one or two bugs on the matter already. They tend to 
work or not work when they shouldn't (mostly work IIRC).

In any case, at this point, all of the @ attributes act like keywords (they 
aren't keywords though, since they aren't valid attributes). There's really no 
difference between nothrow and @safe except what they do. _All_ of a 
function's attributes are actually part of its signature (except perhaps for 
deprecated). The fact that a particular attribute is a keyword while another 
starts with @ is very nearly completely arbitrary. If another language has it 
as a keyword (such as public or const), then it's a keyword, but beyond that, 
whether a particular attribute is a keyword or @ is completely arbitrary. 
IIRC, some of them flipflopped between keyword and @, and there was some 
debate on what should be what, but in the end, I'm not sure that there was 
much planning with regards to what got @ and what didn't. @ seems to have been 
introduced primarily as a way to avoid creating more keywords. Some of us are 
hoping that we'll get user-defined attributes at some point, but the @ 
attributes don't work that way at all at this point (though I don't see why 
they couldn't just be considered as reserved attribute names and special-cased 
by the compiler if and when we get user-defined attributes).

So, in the end, keyword vs @ is pretty arbitrary. Don't try and categorize @ 
attributes differently from keyword attributes, because there really is no 
difference.

- Jonathan M Davis