On Friday, April 19, 2019 7:52:13 AM MDT Adam D. Ruppe via Digitalmars-d wrote:
> On Friday, 19 April 2019 at 12:23:08 UTC, Andrei Alexandrescu
>
> wrote:
> > (There's opting out of @safe by using @system or @trusted.)
>
> This still doesn't work correctly for templates, which should be inferred based on input, not forced one way or another.
>
> We should be doing
>
> attr(true | false | null)
>
> three way!
>
>
> But yeah, that's where I would focus too. Then your modules can opt in pretty easily.

Definitely - though I'm not quite sure how allowing null would work with allowing expressions that result in bool, which is what we really should be doing rather than requiring an explicit true or false. It can obviously be done, but I'm not quite sure how that would be spec-ed out.

- Jonathan M Davis

On Friday, 19 April 2019 at 21:46:20 UTC, Jonathan M Davis wrote:

>> We should be doing
>>
>> attr(true | false | null)
>>
>> three way!
>>
>>
>> But yeah, that's where I would focus too. Then your modules can opt in pretty easily.
>
> Definitely - though I'm not quite sure how allowing null would work with allowing expressions that result in bool, which is what we really should be doing rather than requiring an explicit true or false. It can obviously be done, but I'm not quite sure how that would be spec-ed out.

I think we could make it an enum:

enum AttributeState
{
    yes,
    no,
    infer
}

Then the compiler will take `pure(MyCoolExpression)` and rewrite it to `pure(_d_setAttributeState(MyCoolExpression))`.  In druntime we then implement an overloaded `AttributeState _d_setAttributeState(T)(T value)` to do the right thing.

The spec can say we allow any expression that evaluates to `bool` or `typeof(null)` at compile-time. `_d_setAttributeState`, through D's metaprogramming and design-by-introspection abilities, can implement the spec to translate a `bool` or `typeof(null)` expression to an `AttributeState` value.


Mike