November 08, 2012
Am 08.11.2012 02:48, schrieb Walter Bright:
> On 11/7/2012 4:03 PM, Andrei Alexandrescu wrote:
>> On 11/7/12 10:24 PM, Walter Bright wrote:
>>> On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
>>>> I we were to allow for @foobar style UDA then "safe" would have to be
>>>> a reserved
>>>> keyword somehow. Otherwise I do not know what this would mean:
>>>>
>>>> struct safe { }
>>>> @safe void foobar() { }
>>>
>>> Yes, I agree this is a significant problem.
>>>
>>
>> I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.
> 
> Consider that if we do that, then someone will need to disambiguate with:
> 
>    @object.safe
> 
> which is ambiguous:
> 
>    @a.b .c x = 3;
> 
> or is it:
> 
>    @a .b.c x = 3;
> 
> ?
> 
> Another problem is it pushes off recognition of @safe from the parser to the semantic analyzer. This has unknown forward reference complications.

In that case $(object.safe) would be required - the shortcut then only
works for simple identifiers and would error out going with the second
option ("object is not an attribute" or something).

Templates basically have the same ambiguity: A!x.y.z
November 08, 2012
On 2012-11-08 04:34, Marco Leise wrote:

> Which features are that? It would likely require a major
> rewrite of many routines. Who would want to go through all
> that and the following wave of bugs - some of which may have
> already occurred in the past.
>
> foreach and scope(...) lowerings are essentially AST
> operations. Are there other D features you would implement as
> AST processing, maybe a link to an earlier post ?

"synchronized" is another that I think would be easy to do with AST macros. Perhaps "with". It's probably not worth replacing existing language features with macros just for the sake of it. But for future features AST macros could perhaps be used instead.

> How close is Rust currently to offering flexible AST
> manipulation for lowerings/attributes/macros, does anyone
> know ?

I have no idea. I haven't looked at Rust in this area.

-- 
/Jacob Carlborg
November 08, 2012
On 2012-11-07 20:40, Jonas Drewsen wrote:

> I we were to allow for @foobar style UDA then "safe" would have to be a
> reserved keyword somehow. Otherwise I do not know what this would mean:
>
> struct safe { }
> @safe void foobar() { }

The current attributes are keywords from a user/developer point view.

-- 
/Jacob Carlborg
November 08, 2012
On 2012-11-08 02:48, Walter Bright wrote:

> Consider that if we do that, then someone will need to disambiguate with:
>
>     @object.safe
>
> which is ambiguous:
>
>     @a.b .c x = 3;
>
> or is it:
>
>     @a .b.c x = 3;
>
> ?

I would say:

@a.b .c x = 3;

I mean, we read left to right, at least with source code. But as Sönke said, that could require parentheses:

@(a.b) .c x = 3;

> Another problem is it pushes off recognition of @safe from the parser to
> the semantic analyzer. This has unknown forward reference complications.

Just make it a keyword? The current attributes are already keywords from a user/developer point of view.

-- 
/Jacob Carlborg
November 08, 2012
On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu wrote:
> On 11/7/12 10:24 PM, Walter Bright wrote:
>> On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
>>> I we were to allow for @foobar style UDA then "safe" would have to be
>>> a reserved
>>> keyword somehow. Otherwise I do not know what this would mean:
>>>
>>> struct safe { }
>>> @safe void foobar() { }
>>
>> Yes, I agree this is a significant problem.
>>
>
> I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.

The original argument that the @ in front of @safe is a way to prevent introducing new keywords is all gone then since "safe" becomes a normal symbol which is reserved in the library and in the compiler to let it do its magic.

Then @safe could just as well be a normal builtin storage class called "safe".

* Plopping types "safe","nothrow" etc. into object.di would be a breaking change.
* Making @safe, @nothrow into keywords called "safe", "nothrow" would be breaking change.

The latter would be the cleanest cut and not have the semantic/parse stage problems that Walter mentioned.

Another option would to enforce parenthesis @(safe) for UDA which would make it less nice for the eyes to look at.

/Jonas


November 08, 2012
On Thursday, 8 November 2012 at 11:01:13 UTC, Jonas Drewsen wrote:
> On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu wrote:
>> On 11/7/12 10:24 PM, Walter Bright wrote:
>>> On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
>>>> I we were to allow for @foobar style UDA then "safe" would have to be
>>>> a reserved
>>>> keyword somehow. Otherwise I do not know what this would mean:
>>>>
>>>> struct safe { }
>>>> @safe void foobar() { }
>>>
>>> Yes, I agree this is a significant problem.
>>>
>>
>> I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.
>
> The original argument that the @ in front of @safe is a way to prevent introducing new keywords is all gone then since "safe" becomes a normal symbol which is reserved in the library and in the compiler to let it do its magic.
>
> Then @safe could just as well be a normal builtin storage class called "safe".
>
> * Plopping types "safe","nothrow" etc. into object.di would be a breaking change.
> * Making @safe, @nothrow into keywords called "safe", "nothrow" would be breaking change.
>
> The latter would be the cleanest cut and not have the semantic/parse stage problems that Walter mentioned.
>
> Another option would to enforce parenthesis @(safe) for UDA which would make it less nice for the eyes to look at.
>
> /Jonas

Not safe but @safe should become a keyword.
November 08, 2012
On 2012-11-07 22:16, Timon Gehr wrote:

> Text interpolation.
>
> enum d = "c";
>
> mixin(X!"abc@(d)ef"); // -> abccef
>
> I use it mostly for code generation.
>
> mixin(mixin(X!q{
>      if(@(a)) @(b);
> }));

This is what we need AST macros for.

-- 
/Jacob Carlborg
November 08, 2012
11/7/2012 5:40 PM, deadalnix пишет:
[snip]
>> [], because @ should be reserved for future language keywords.
>>
>> Whenever people post suggested language features that require some
>> marking, they introduce a new @attribute, because introducing a plain
>> keyword breaks code. If you have @UDAs, this further limits language
>> expansion.
>>
>> Example: let's say you want to introduce a "nogc" mark:
>> 1. Not a nogc keyword, that could break "bool nogc;"
>> 2. If you have @, @nogc could break an "enum nogc;" attribute.
>> 3. Now you're stuck with __nogc or #nogc or something uglier.
>>
>> There is a familiar-to-other-langauges advantage to @, but there is a
>> better-than-other-languages advantage to [].
>>
>> My thoughts,
>> NMS
>
> I think D has already too many feature, and that many of them can be
> implemented as attribute + AST processing.

+1

>
> D should work toward getting this AST stuff and stop adding new keywords
> all the time.

-- 
Dmitry Olshansky
November 08, 2012
On Thu, 08 Nov 2012 21:53:11 +0400
Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 11/7/2012 5:40 PM, deadalnix пишет:
> >
> > I think D has already too many feature, and that many of them can be implemented as attribute + AST processing.
> 
> +1
> 

Doesn't that still amount to the same amount of features though? At
least from the user's standpoint anyway. Plus, I would imagine
that library-implemented features would be slower to compile (simply
because it's just that much more to be compiled).

Not that I'm necessarily saying "Always stuff everything into the language forever!" I just don't see it as quite so clear-cut.

November 08, 2012
On Thu, 8 Nov 2012 14:27:14 -0500
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> [...]Plus, I would imagine
> that library-implemented features would be slower to compile (simply
> because it's just that much more to be compiled).

Also, these particular sorts of things (compile time processing of things that are in-library) essentially amount to executing interpreted code to compile. Sure, that's very powerful, and very well worth having, but should it really be done for very common features? For common features, I'd imagine native non-"interpreted" support would help compilation speed, which is one of D's major goals and benefits. Suddenly interpreting large parts of the language might work against that.

> 
> Not that I'm necessarily saying "Always stuff everything into the language forever!" I just don't see it as quite so clear-cut.
>