On Thu, 04 Jun 2015 08:45:34 +0200
Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 2015-06-02 12:29, Daniel Kozak wrote:
> > I am working on dip which will try to addressed negation of
> > attributes issue.
> > http://wiki.dlang.org/DIP79
> 
> What happens if you use this syntax for a UDA, compile time error?
> 

Yes, but currently with not perfect error message :)

On Wed, 03 Jun 2015 14:49:31 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> On 6/3/15 2:19 PM, Jonathan M Davis wrote:
> > Regardless, I think that attribute(boolean expression) is the clear winner, because it's for more flexible.
> 
> Yes please. -- Andrei

Are we ok with code like this:

final(someTemplate!orMaybeSomeAnother!SomeValue)
finalOrVIrtualmethodWhoKnows() {}

?

Maybe we can start with just attr(false) and attr(true), and add
complete bool expresion evaluation in future?

On Thu, 04 Jun 2015 09:13:47 +0200, Daniel Kozák via Digitalmars-d wrote:

> On Wed, 03 Jun 2015 14:49:31 -0700 Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com>
> wrote:
> 
>> On 6/3/15 2:19 PM, Jonathan M Davis wrote:
>> > Regardless, I think that attribute(boolean expression) is the clear winner, because it's for more flexible.
>> 
>> Yes please. -- Andrei
> 
> Are we ok with code like this:
> 
> final(someTemplate!orMaybeSomeAnother!SomeValue)
> finalOrVIrtualmethodWhoKnows() {}
> 
> ?
> 
> Maybe we can start with just attr(false) and attr(true), and add
> complete bool expresion evaluation in future?

:-(

On Wed, 03 Jun 2015 21:19:19 +0000
Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
> > I am working on dip which will try to addressed negation of
> > attributes issue.
> > http://wiki.dlang.org/DIP79
> 
> You need to iron out what happens with attributes like @safe/@trusted/@system or public/protected/package/private.


nothing, there is no need to revert them or do anything special

> Simply turning them on and off doesn't really work.
> 
> Regardless, I think that attribute(boolean expression) is the clear winner, because it's for more flexible. Without the ability to provide a boolean expression, some code will be forced to use compile-time introspection to determine which attributes are enabled and then enable or disable them as appropriate in different static if branches. That sort of case is really only going to pop up in generic code, but once you start turning attributes on and off, I fully expect that it will come up, in which case, a syntax such as !final won't work very well.
Yes I know, but I still do not feel right about that.

On Thursday, 4 June 2015 at 07:14:00 UTC, Daniel Kozák wrote:
>
> On Wed, 03 Jun 2015 14:49:31 -0700
> Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
> wrote:
>
>> On 6/3/15 2:19 PM, Jonathan M Davis wrote:
>> > Regardless, I think that attribute(boolean expression) is the clear
>> > winner, because it's for more flexible.
>> 
>> Yes please. -- Andrei
>
> Are we ok with code like this:
>
> final(someTemplate!orMaybeSomeAnother!SomeValue)
> finalOrVIrtualmethodWhoKnows() {}
>
> ?

Yes, we're okay with that. That's precisely why we want it. And yes, it could be abused, but when dealing with generic code, but without it, things get a _lot_ uglier when you need to be doing introspection to determine what they should be (you'll end up with static if-else trees with almost duplicate declarations otherwise). A prime example would be when forwarding the attributes of a type that you're wrapping (like a range). If you need the attributes to match the ones being wrapped, then it's _way_ cleaner to be able to do something like

auto front() const(isConst!(_wrapped.front)) { return _wrapped.front; }

than if we only had const and !const. What we have now in this sort of situation is ugly enough, and this is a good opportunity to improve it. It would also be less error-prone than how we're stuck doing it now.

> Maybe we can start with just attr(false) and attr(true), and add
> complete bool expresion evaluation in future?

What would be the point of that? If all we're planning to do is have true and false, then you might as well just do attr and !attr. Accepting a boolean does nothing more for you unless it'll take arbitrary, compile-time expressions that resolve to a boolean.

- Jonathan M Davis

On Thu, 04 Jun 2015 08:31:30 +0000
Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Thursday, 4 June 2015 at 07:14:00 UTC, Daniel Kozák wrote:
> >
> > On Wed, 03 Jun 2015 14:49:31 -0700
> > Andrei Alexandrescu via Digitalmars-d
> > <digitalmars-d@puremagic.com>
> > wrote:
> >
> >> On 6/3/15 2:19 PM, Jonathan M Davis wrote:
> >> > Regardless, I think that attribute(boolean expression) is
> >> > the clear
> >> > winner, because it's for more flexible.
> >> 
> >> Yes please. -- Andrei
> >
> > Are we ok with code like this:
> >
> > final(someTemplate!orMaybeSomeAnother!SomeValue)
> > finalOrVIrtualmethodWhoKnows() {}
> >
> > ?
> 
> Yes, we're okay with that. That's precisely why we want it. And yes, it could be abused, but when dealing with generic code, but without it, things get a _lot_ uglier when you need to be doing introspection to determine what they should be (you'll end up with static if-else trees with almost duplicate declarations otherwise). A prime example would be when forwarding the attributes of a type that you're wrapping (like a range). If you need the attributes to match the ones being wrapped, then it's _way_ cleaner to be able to do something like
> 
> auto front() const(isConst!(_wrapped.front)) { return _wrapped.front; }
> 
> than if we only had const and !const. What we have now in this sort of situation is ugly enough, and this is a good opportunity to improve it. It would also be less error-prone than how we're stuck doing it now.
> 
> > Maybe we can start with just attr(false) and attr(true), and add
> > complete bool expresion evaluation in future?
> 
> What would be the point of that? If all we're planning to do is have true and false, then you might as well just do attr and !attr. Accepting a boolean does nothing more for you unless it'll take arbitrary, compile-time expressions that resolve to a boolean.
> 
> - Jonathan M Davis

If I will go with !attr, there will be no way to add compile-time expressions to it. But if we start with attr(true) or attr(false), it can be easily extended to support compile-time expressions in future.

On Thursday, 4 June 2015 at 08:31:32 UTC, Jonathan M Davis wrote:
> Yes, we're okay with that. That's precisely why we want it. And yes, it could be abused, but when dealing with generic code, but without it, things get a _lot_ uglier when you need to be doing introspection to determine what they should be (you'll end up with static if-else trees with almost duplicate declarations otherwise). A prime example would be when forwarding the attributes of a type that you're wrapping (like a range). If you need the attributes to match the ones being wrapped, then it's _way_ cleaner to be able to do something like
>
> auto front() const(isConst!(_wrapped.front)) { return _wrapped.front; }
>
> than if we only had const and !const. What we have now in this sort of situation is ugly enough, and this is a good opportunity to improve it. It would also be less error-prone than how we're stuck doing it now.
>
>> Maybe we can start with just attr(false) and attr(true), and add
>> complete bool expresion evaluation in future?
>
> What would be the point of that? If all we're planning to do is have true and false, then you might as well just do attr and !attr. Accepting a boolean does nothing more for you unless it'll take arbitrary, compile-time expressions that resolve to a boolean.
>
> - Jonathan M Davis

It's still trivial to do this without allowing arbitrary expressions, since the expressions have to be CTFE-able.

enum constIsEnabled = isConst!(_wrapped.front);
auto front() const(constIsEnabled) { return _wrapped.front; }

On 4 June 2015 at 10:46, Daniel Kozák via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
> On Thu, 04 Jun 2015 08:31:30 +0000
> Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> > On Thursday, 4 June 2015 at 07:14:00 UTC, Daniel Kozák wrote:
> > >
> > > On Wed, 03 Jun 2015 14:49:31 -0700
> > > Andrei Alexandrescu via Digitalmars-d
> > > <digitalmars-d@puremagic.com>
> > > wrote:
> > >
> > >> On 6/3/15 2:19 PM, Jonathan M Davis wrote:
> > >> > Regardless, I think that attribute(boolean expression) is
> > >> > the clear
> > >> > winner, because it's for more flexible.
> > >>
> > >> Yes please. -- Andrei
> > >
> > > Are we ok with code like this:
> > >
> > > final(someTemplate!orMaybeSomeAnother!SomeValue)
> > > finalOrVIrtualmethodWhoKnows() {}
> > >
> > > ?
> >
> > Yes, we're okay with that. That's precisely why we want it. And yes, it could be abused, but when dealing with generic code, but without it, things get a _lot_ uglier when you need to be doing introspection to determine what they should be (you'll end up with static if-else trees with almost duplicate declarations otherwise). A prime example would be when forwarding the attributes of a type that you're wrapping (like a range). If you need the attributes to match the ones being wrapped, then it's _way_ cleaner to be able to do something like
> >
> > auto front() const(isConst!(_wrapped.front)) { return
> > _wrapped.front; }
> >
> > than if we only had const and !const. What we have now in this sort of situation is ugly enough, and this is a good opportunity to improve it. It would also be less error-prone than how we're stuck doing it now.
> >
> > > Maybe we can start with just attr(false) and attr(true), and add
> > > complete bool expresion evaluation in future?
> >
> > What would be the point of that? If all we're planning to do is have true and false, then you might as well just do attr and !attr. Accepting a boolean does nothing more for you unless it'll take arbitrary, compile-time expressions that resolve to a boolean.
> >
> > - Jonathan M Davis
>
> If I will go with !attr, there will be no way to add compile-time expressions to it. But if we start with attr(true) or attr(false), it can be easily extended to support compile-time expressions in future.
>
>

I don't see how having !attr will add value to D.

2015-06-04 22:41 GMT+09:00 Meta via Digitalmars-d < digitalmars-d@puremagic.com>:

> It's still trivial to do this without allowing arbitrary expressions, since the expressions have to be CTFE-able.
>
> enum constIsEnabled = isConst!(_wrapped.front);
> auto front() const(constIsEnabled) { return _wrapped.front; }
>

In old days I thought a little more generic idea "compilable attribute".

For example:

    // label style.
    // `str` is a CTFEable expression that returns
    // "public", "final", or other built-in attribute name.
    mixin(str): void f1() {}

    // block style
    mixin(str) { void f2() {} }

    // prefix style
    mixin(str) void f3() {}

    // postfix style
    void f4() mixin(str) {}

Similar thing for UDAs

    // tuple contains CT entities that could be UDA.
    @mixin(tuple):

(Note that there's no consideration for feasibility).

But I couldn't find the use case of them.

Kenji Hara

On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
> I am working on dip which will try to addressed negation of attributes issue.
> http://wiki.dlang.org/DIP79

More general: attribute(Args...)

safety(Safety.Pure):
access(Access.Private): // assume private/protected/... is pseudo attributes
access(Access.Package, "some.module"):
override(Object): // override only Objects methods. IMO good idea to group method by owner
override(false):

cons:
New keywords for same things. It hints things like __access. Ugly things:(
New ways for same things
Ugly