This came to mind while working on a set of containers.

@safety often comes with a performance cost. For example, any container that wants to give out a range or iterator has to have a ref-counted or GC allocted payload to ensure safety. In a high-performance context though, the performance hit may be unacceptable.

It's fairly easy to make a container that toggles it's implementation between  ref-counted, GC, or raw pointers/arrays, based on a template parameter. This would allow a single container to be used in both performance sensitive and safe contexts (in theory). The only problem would be the lack of actual @safe annotations on the container, as they would only be applicable to one variant, and otherwise cause a compile-time error.

One solution could be this:

struct Container(T, bool safetyOn = true)
{
	static if(safe)
		RefCounted!(T[]) data;
	else
		T[] data;
		
	auto opSlice() @safe(safetyOn) {
		return Range(data, 0, data.length);
	}
}

A similar solution could be applied to @nogc as well.

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
> This came to mind while working on a set of containers.
>
> [...]
> One solution could be this:
>
> struct Container(T, bool safetyOn = true)
> {
> 	static if(safe)
> 		RefCounted!(T[]) data;
> 	else
> 		T[] data;
> 		
> 	auto opSlice() @safe(safetyOn) {
> 		return Range(data, 0, data.length);
> 	}
> }
>
> A similar solution could be applied to @nogc as well.

Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
> The only problem would be the lack of actual @safe annotations on the container, as they would only be applicable to one variant, and otherwise cause a compile-time error.
> [...]

Shouldn't the already compiler derive the appropriate attributes (@safe/@system, @nogc) for functions inside templates?

On 17.08.2017 18:36, HyperParrow wrote:
> On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
>> This came to mind while working on a set of containers.
>>
>> [...]
>> One solution could be this:
>>
>> struct Container(T, bool safetyOn = true)
>> {
>>     static if(safe)
>>         RefCounted!(T[]) data;
>>     else
>>         T[] data;
>>
>>     auto opSlice() @safe(safetyOn) {
>>         return Range(data, 0, data.length);
>>     }
>> }
>>
>> A similar solution could be applied to @nogc as well.
> 
> Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.

That makes little sense to me, as DIP 1012 is strictly more general.

template safety(bool safetyOn){ // (this can even be in core)
    static if(safetyOn) alias safety = FunctionSafety.safe;
    else alias safety = FunctionSafety.system;
    // else alias safety = infer!FunctionSafety; // even better!
}

struct Container(T, bool safetyOn = true){
    static if(safe) RefCounted!(T[]) data;
    else T[] data;

    auto opSlice() @safety!safetyOn {
        return Range(data, 0, data.length);
    }
}

On Thursday, 17 August 2017 at 17:21:16 UTC, Timon Gehr wrote:
> On 17.08.2017 18:36, HyperParrow wrote:
>> On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
>>> [...]
>> 
>> Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.
>
> That makes little sense to me, as DIP 1012 is strictly more general.
>
> template safety(bool safetyOn){ // (this can even be in core)
>     static if(safetyOn) alias safety = FunctionSafety.safe;
>     else alias safety = FunctionSafety.system;
>     // else alias safety = infer!FunctionSafety; // even better!
> }
>
> struct Container(T, bool safetyOn = true){
>     static if(safe) RefCounted!(T[]) data;
>     else T[] data;
>
>     auto opSlice() @safety!safetyOn {
>         return Range(data, 0, data.length);
>     }
> }

The application of DIP 1012 would have catastrophic effects on the current tooling but as usual nobody thinks to that.

On 17.08.2017 20:38, HypperParrow wrote:
> On Thursday, 17 August 2017 at 17:21:16 UTC, Timon Gehr wrote:
>> On 17.08.2017 18:36, HyperParrow wrote:
>>> On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
>>>> [...]
>>>
>>> Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.
>>
>> That makes little sense to me, as DIP 1012 is strictly more general.
>>
>> template safety(bool safetyOn){ // (this can even be in core)
>>     static if(safetyOn) alias safety = FunctionSafety.safe;
>>     else alias safety = FunctionSafety.system;
>>     // else alias safety = infer!FunctionSafety; // even better!
>> }
>>
>> struct Container(T, bool safetyOn = true){
>>     static if(safe) RefCounted!(T[]) data;
>>     else T[] data;
>>
>>     auto opSlice() @safety!safetyOn {
>>         return Range(data, 0, data.length);
>>     }
>> }
> 
> The application of DIP 1012 would have catastrophic effects on the current tooling but as usual nobody thinks to that.

AFAICT, both of those claims are exaggerations. How exactly would it be "catastrophic"? This feature is easy to implement (basically, it just patches together a couple of existing pieces).

On Thursday, 17 August 2017 at 18:38:40 UTC, HypperParrow wrote:
> On Thursday, 17 August 2017 at 17:21:16 UTC, Timon Gehr wrote:
>> On 17.08.2017 18:36, HyperParrow wrote:
>>> On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
>>>> [...]
>>> 
>>> Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.
>>
>> That makes little sense to me, as DIP 1012 is strictly more general.
>>
>> template safety(bool safetyOn){ // (this can even be in core)
>>     static if(safetyOn) alias safety = FunctionSafety.safe;
>>     else alias safety = FunctionSafety.system;
>>     // else alias safety = infer!FunctionSafety; // even better!
>> }
>>
>> struct Container(T, bool safetyOn = true){
>>     static if(safe) RefCounted!(T[]) data;
>>     else T[] data;
>>
>>     auto opSlice() @safety!safetyOn {
>>         return Range(data, 0, data.length);
>>     }
>> }
>
> The application of DIP 1012 would have catastrophic effects on the current tooling but as usual nobody thinks to that.

How? In the Simplest terms DIP1012 replaces Keyword attributes with enums. Yes, libdparse would have to be updated, but that is the case for any substantial DIP. Hardly 'catastrophic'.

On Thursday, August 17, 2017 19:21:16 Timon Gehr via Digitalmars-d wrote:
> On 17.08.2017 18:36, HyperParrow wrote:
> > On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
> >> This came to mind while working on a set of containers.
> >>
> >> [...]
> >> One solution could be this:
> >>
> >> struct Container(T, bool safetyOn = true)
> >> {
> >>
> >>     static if(safe)
> >>
> >>         RefCounted!(T[]) data;
> >>
> >>     else
> >>
> >>         T[] data;
> >>
> >>     auto opSlice() @safe(safetyOn) {
> >>
> >>         return Range(data, 0, data.length);
> >>
> >>     }
> >>
> >> }
> >>
> >> A similar solution could be applied to @nogc as well.
> >
> > Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.
>
> That makes little sense to me, as DIP 1012 is strictly more general.

Whereas this solves the problem with DIP 1012 claims to be solving without adding a bunch of extra stuff that IMHO makes the built-in attributes more complicated for no real benefit as well as having some stuff in it that would effectively split the language into multiple variants where code will compile with some but not others (most notably, allowing for the default @safety level to be globally altered as opposed to doing something nice and portable like @safe: at the top of a module). As I explained in the initial discussion in DIP 1012, it does a whole pile of stuff that has nothing to do with its stated goal, and I think that most of the other stuff that it does is detrimental, whereas if what's proposed here were implemented for more than just @safe, it would actually solve the stated goal of allowing attributes to be negated and thus fix the problem that doing something like putting final: at the top of a class can't be undone.

Andrei previously proposed essentially what the OP proposed, but no DIP was ever created for it, and it's never happened. It probably would stand a decent chance of making it through though, since it solves a real problem, and Andrei has previously shown interest in this solution.

- Jonathan M Davis

On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:
> On Thursday, August 17, 2017 19:21:16 Timon Gehr via
>> That makes little sense to me, as DIP 1012 is strictly more general.
>
> Whereas this solves the problem with DIP 1012 claims to be solving without adding a bunch of extra stuff that IMHO makes the built-in attributes more complicated for no real benefit as well as having some stuff in it that would effectively split the language into multiple variants where code will compile with some but not others (most notably, allowing for the default @safety level to be globally altered as opposed to doing something nice and portable like @safe: at the top of a module).

As I explained in that thread it adds very little complication, keyword like attributes become enum; last applied wins. If anything its reduces complexity as attributes, both builtin and user defined, become regular attributes. W.r.t global altering, I expect that it would be used by applications (rarely, e.g. embedded environments for nothrow nogc final) not libraries. It is also only part of the DIP.

>As I explained in the initial discussion in DIP 1012,
> it does a whole pile of stuff that has nothing to do with its stated goal, and I think that most of the other stuff that it does is detrimental, whereas if what's proposed here were implemented for more than just @safe, it would actually solve the stated goal of allowing attributes to be negated and thus fix the problem that doing something like putting final: at the top of a class can't be undone.

If you think that then I have clearly failed to express the DIP at all.
It solves exactly that. I completely fail to see how it is a detriment to anything.
The 'whole pile of other stuff' is reduced in further revisions to the DIP.

> Andrei previously proposed essentially what the OP proposed, but no DIP was ever created for it, and it's never happened. It probably would stand a decent chance of making it through though, since it solves a real problem, and Andrei has previously shown interest in this solution.

And there was real interest in DIP 1012, which was the whole reason I wrote it, and
I reject your notion that DIP 1012 does not solve a problem.

On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:
> [...]
>
> - Jonathan M Davis

Makes sense to me.

The first question that comes to mind is if the extra generality provided by DIP 1012 is actually useful, let alone, worth breaking changes. The rationale section of the DIP only mentions negating attributes, which is easily accomplished with what I suggested. Unless that section is expanded with additional practical use cases, then it doesn't seem worth the trouble to me.

The DIP mentions tagging a module declaration with default attributes. If the whole purpose of the DIP is to allow for negating attributes, why would you even need this change, when the DIP would effectively make it ok to put "@nogc: @safe: @etc:" at the top of the file?

My suggestion does not cover "inferred" as discussed in the DIP, but that could be achieved by letting something like "@default" reset all attributes for a given symbol.

I'll concede that DIP1012 makes more logical sense than the current state of things, but it seems like something that would be best achieved during a transition to a subsequent language version. It seems commonplace here, to discard suggestions based on their current viability, when it may be better to add them to a feature backlog that could be considered when talking about the possibility of a D3.