Le 20/03/2012 17:13, Andrei Alexandrescu a écrit :
> On 3/20/12 10:52 AM, Jacob Carlborg wrote:
>> On 2012-03-20 16:17, Andrei Alexandrescu wrote:
>>> On 3/20/12 12:50 AM, Kapps wrote:
>>
>>> Perhaps we should add a field of type Variant[string].
>>
>> No, not Variant[string] again.
>
> Why? I thought it was agreed that that's a good idea for exceptions.
>

I was probably one of the most controversial part of the thread :D

Le 20/03/2012 20:17, Andrei Alexandrescu a écrit :
> On 3/20/12 2:04 PM, Piotr Szturmaj wrote:
>> Andrei Alexandrescu wrote:
>>> On 3/20/12 10:52 AM, Jacob Carlborg wrote:
>>>> On 2012-03-20 16:17, Andrei Alexandrescu wrote:
>>>>> On 3/20/12 12:50 AM, Kapps wrote:
>>>>
>>>>> Perhaps we should add a field of type Variant[string].
>>>>
>>>> No, not Variant[string] again.
>>>
>>> Why? I thought it was agreed that that's a good idea for exceptions.
>>
>> Please, do not transform D into a dynamic language.
>
> Where's the "dynamic languages rok" crowd when you need it :o).
>
> Andrei

They are busy debugging what they coded sooooooo quickly and efficiently.

Le 20/03/2012 17:16, Andrei Alexandrescu a écrit :
> Maybe there's a better approach than flectioned. Consider the language
> is frozen solid. How would you solve problems with it?
>

Easy, I already did that many times. I'd preprocess the source code with some homebrew tool before compiling.

On 2012-03-20 17:13, Andrei Alexandrescu wrote:
> On 3/20/12 10:52 AM, Jacob Carlborg wrote:
>> On 2012-03-20 16:17, Andrei Alexandrescu wrote:
>>> On 3/20/12 12:50 AM, Kapps wrote:
>>
>>> Perhaps we should add a field of type Variant[string].
>>
>> No, not Variant[string] again.
>
> Why? I thought it was agreed that that's a good idea for exceptions.

Maybe you agreed on that. I still don't like it.

-- 
/Jacob Carlborg

Le 16/03/2012 17:09, Andrei Alexandrescu a écrit :
> On 3/16/12 8:35 AM, Adam D. Ruppe wrote:
>> enum Serializable { yes, no }
>>
>> @note(Serializable.yes) int a;
> [...]
>> foreach(i, exp; __traits(getNotes, a)) {
>> static assert(is(typeof(exp) == Serializable);
>> static assert(exp == Serializable.yes);
>> }
>
> So we have:
>
> class A {
> @note(Serializable.yes) int a;
> ...
> }
>
> vs. a hypothetical in-language solution:
>
> class A {
> int a;
> mixin(note("a", Serializable.yes));
> ...
> }
>
> I wonder to what extent the in-language solution can be made to work.
>
>
> Andrei

It is more tricky if the property isn't a simple attribute to read. Again, consider what is done with this simple example : http://projectlombok.org/

We have the opportunity here to introduce in D the concept of aspect oriented programming. This is HUGE. If you are afraid of the addition of a functionnality to the language, don"t worry, you are not just adding a functionnality, but a whole new paradigm.

And, BTW, this would allow us to drop some functionalities that now can be provided by phobos (synchronized for example is an obvious one). Same goes for override, deprecated, and the fun thing is that we can implement our own to extends the language even more as lib.

Even the propagation of pure, @safe, nothrow and const that has been discussed recently can be done with that feature.

If you are worried about introducing language features (I am) you should definitively introduce that one, because lot of features has already been included just because that one is lacking.

Adding compile time information to a type is the visible part of the iceberg. Really.

On 2012-03-20 20:17, Andrei Alexandrescu wrote:
> On 3/20/12 2:04 PM, Piotr Szturmaj wrote:
>> Please, do not transform D into a dynamic language.
>
> Where's the "dynamic languages rok" crowd when you need it :o).
>
> Andrei

They left you behind after all those "d rox" comments :)

-- 
/Jacob Carlborg

Le 16/03/2012 19:23, Andrej Mitrovic a écrit :
> On 3/16/12, Adam D. Ruppe<destructionator@gmail.com>  wrote:
>> The current language solution isn't really *bad* with enough
>> library help, but it isn't particularly *good* either and I
>> don't think it can be. I've tried a few things, and I still
>> see the lack of user annotations as D's biggest miss right now.
>
> Yeah, but I would say if we had even better compile-time introspection
> we could have the freedom to implement any number of annotation
> implementations in library code. When you put something into the
> language you have to depend on C++ hackers to implement and then
> inevitably fix the upcoming bugs in the front-end (ICEs are an
> annoying blocker), and there's always that issue where the devs are
> against adding new features to an existing language feature. (say
> annotations were implemented, soon enough someone is going to complain
> it doesn't have enough functionality and that it needs to be
> extended).
>
> Personally I'd love it if we had more __traits and compile-time
> introspection abilities.

And not just introspection, but modification would be king.

Le 16/03/2012 18:36, Adam D. Ruppe a écrit :
> On Friday, 16 March 2012 at 16:57:26 UTC, Steven Schveighoffer wrote:
>> I thought @<symbol> was supposed to be a user-defined annotation.
>> Otherwise, why did we introduce @syntax?
>
> idk, to "reduce" the number of keywords or somethiny.
>
> This is why I call it a mistake or missed opportunity
> right now though: @property, @safe, @disable, @system,
> and @trusted have already made a claim on the @syntax.
>
> Now, we have to work around that, which is why I'm
> thinking @note(expression) rather than @<something>.
>
>> I'd rather see something like this:
>
> I could live with that too, but I think it'd be harder
> to make happen due to potential clashes with the current
> thing @ is used for.

This isn't a problem because they'd be scoped to the module anyway. D have no top level names, except for the one provided by the compiler, and that is great !

On 3/20/12 4:36 PM, deadalnix wrote:
> We have the opportunity here to introduce in D the concept of aspect
> oriented programming. This is HUGE. If you are afraid of the addition of
> a functionnality to the language, don"t worry, you are not just adding a
> functionnality, but a whole new paradigm.

I dabbled into AOP quite a bit, but I'm not all that jazzed about it. It's been around for quite a while but it has little to show for it. At the present it's rather unstructured and lacks a strong corpus of useful idioms. I'd say - interesting, but I wouldn't bet the farm on it.

Andrei

Le 20/03/2012 22:36, Andrei Alexandrescu a écrit :
> On 3/20/12 4:36 PM, deadalnix wrote:
>> We have the opportunity here to introduce in D the concept of aspect
>> oriented programming. This is HUGE. If you are afraid of the addition of
>> a functionnality to the language, don"t worry, you are not just adding a
>> functionnality, but a whole new paradigm.
>
> I dabbled into AOP quite a bit, but I'm not all that jazzed about it.
> It's been around for quite a while but it has little to show for it. At
> the present it's rather unstructured and lacks a strong corpus of useful
> idioms. I'd say - interesting, but I wouldn't bet the farm on it.
>
> Andrei
>

Honestly, AOP is quite hard to use right now because of the lack of language support. This is a chicken and egg issue.

This is more and more used in Java, for good reasons. I think we will sooner or later talk about modern Java like we talk about modern C++ today.

You are well placed to know how template have been implemented in C++ simply for generic, and what comes out of it. And how awesome that is.

Many feature of the current D could have been implemented using AOP. I think that pretty much made the point. AOP is useful, and as a proof emulating it by compiler magic, when we cannot do without (synchronized, override, deprecated, as examples).

If AOP wasn't useful, theses feature wouldn't have been included in D at all. I'm suggesting templates, your answering « everything is a object, so let's do generic, I don't see the point of templates ».