11/8/2012 11:34 PM, Nick Sabalausky пишет:
> 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.

If we finally get to the usual byte-code interpreter then it is more the sufficiently fast to do trivial re-writes that features like synchronized are all about.

Anyway I'm not for trying to redo all (if any) of the built-in stuff. If it's bug free and works, fine let it be. We can't remove it anyway. I just anticipate a couple more features to crop up if UDA dropping from nowhere is any indicator. And then another tiny most useful thing, and another one, and ...

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


-- 
Dmitry Olshansky

Le 08/11/2012 20:27, Nick Sabalausky a écrit :
> 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.
>

It have several advantages.

It is easy to test a feature as a lib, and then include it later in the standard lib if it does make sense. This is a great improvement as it don't require hacking the compiler.

This allow many people to play around with the feature they like without breaking the language in many pieces. As before, successful features can be included.

Implementing a feature don't require anymore to know the compiler internal, and do not require either to know other feature internals.

A new feature in compiler A is available in other compiler as well at the same time. Same goes for tooling around the language. Now, it is almost impossible to provide proper tooling around D because new feature are dropped into dmd master quite often and all tools have to be updated (most people give up at some point).

As of speed, some people, including me but I'm not the only one, are working toward JIT compile for CTFE. With some bytecode caching, I'm pretty sure really good performance can be achieved (unless the feature's implementation suck badly).

Le 08/11/2012 02:48, Walter Bright a écrit :
> 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.

How didn't see that coming. I never was a big fan of .identifier syntax for module level stuff.

However, you example isn't quite correct. Attributes are for symbols, and your example don't create any new symbol.

Let's consider @a.b .c d = 3;

Now, we have several option to disambiguate that. The first, obvious one is to use () : @(a.b) .c d = 3; .

When not using (), the compiler understand this as @(a.b.c) d = 3; which is an error.

Another option is to use auto : @a.b auto d = .c(3);

Anyway, I don't expect this to break too much code, if any.

Le 08/11/2012 01:14, Andrej Mitrovic a écrit :
> On 11/8/12, David Nadlinger<see@klickverbot.at>  wrote:
>> On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu
>> wrote:
>> "nothrow" isn't actually an @attribute. So much for the value of
>> consistency… :o)
>
> Another classic inconsistency:
> @disable and deprecated
>
> Not only that but I keep writing the former as @disabled and get CT errors.

Good new for you, with the given proposal, you'll be able to do


alias deprecate deprecated;

Le 08/11/2012 12:01, Jonas Drewsen a écrit :
> 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
>

nothrow is already a keyword (which is really inconsistent). I'm not sure what it does buy us, and both safe and nothrow are good candidates for lib implementation rather than compiler support.

On 2012-11-09, 15:26, deadalnix wrote:

> Le 08/11/2012 01:14, Andrej Mitrovic a écrit :
>> On 11/8/12, David Nadlinger<see@klickverbot.at>  wrote:
>>> On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu
>>> wrote:
>>> "nothrow" isn't actually an @attribute. So much for the value of
>>> consistency… :o)
>>
>> Another classic inconsistency:
>> @disable and deprecated
>>
>> Not only that but I keep writing the former as @disabled and get CT errors.
>
> Good new for you, with the given proposal, you'll be able to do
>
>
> alias deprecate deprecated;

Or even:

alias deprecated = deprecate;

-- 
Simen

Am Fri, 09 Nov 2012 15:28:40 +0100
schrieb deadalnix <deadalnix@gmail.com>:

> nothrow is already a keyword (which is really inconsistent). I'm not sure what it does buy us, and both safe and nothrow are good candidates for lib implementation rather than compiler support.

That requires that the compiler exposes all sorts of
statistical data for every statement. E.g. to check if nothrow
is violated you have to find statements that throw something
and then check if there is a catch block around that, that
catches it. If a statement is a function call, you would
ask the compiler if that function throws. (In particular if it
is a templated function with deduced 'nothrow' and '@safe').
And there you are at the point that you just duplicated the
compiler code in the library.

-- 
Marco

Am 10.11.2012 11:21, schrieb Marco Leise:
> Am Fri, 09 Nov 2012 15:28:40 +0100
> schrieb deadalnix <deadalnix@gmail.com>:
> 
>> nothrow is already a keyword (which is really inconsistent). I'm not sure what it does buy us, and both safe and nothrow are good candidates for lib implementation rather than compiler support.
> 
> That requires that the compiler exposes all sorts of
> statistical data for every statement. E.g. to check if nothrow
> is violated you have to find statements that throw something
> and then check if there is a catch block around that, that
> catches it. If a statement is a function call, you would
> ask the compiler if that function throws. (In particular if it
> is a templated function with deduced 'nothrow' and '@safe').
> And there you are at the point that you just duplicated the
> compiler code in the library.
> 

Not duplicated, but moved - which results in a simpler compiler implementation, definitely a good thing.

Of course those AST analytics/maccro functionality has to be added in return, but since this has a much broader scope and would make other features (string mixins) obsolete, even that is not quite clear in terms of weight as a counter argument.

Anyway, I surely wouldn't expect this to happen anytime soon, but keeping this path open seems like a wise decision - it's a great opportunity to remove/not add features from/to the language without trading functinality or even syntax.