On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
> In a high-performance context though, the performance hit may be unacceptable.

Well in those super rare situations, there's always the workaround with mixins:

mixin template funcWithAttr(string decl, string attributes, string code) {
    pragma(msg, "<<<" ~ code ~ ">>>");
    mixin(decl ~ attributes ~ "{" ~ code ~" }");
}

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

	mixin funcWithAttr!("auto opSlice()", safetyOn ? "@safe" : "", q{
		return Range(data, 0, data.length);
	});
}

On Saturday, 19 August 2017 at 18:22:58 UTC, Guillaume Boucher wrote:
> On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
>> In a high-performance context though, the performance hit may be unacceptable.
>
> Well in those super rare situations, there's always the workaround with mixins:

Those situations are not rare.

> mixin template funcWithAttr(string decl, string attributes, string code) {
>     pragma(msg, "<<<" ~ code ~ ">>>");
>     mixin(decl ~ attributes ~ "{" ~ code ~" }");
> }
>
> struct Container(T, bool safetyOn = true)
> {
> 	static if(safe)
> 		RefCounted!(T[]) data;
> 	else
> 		T[] data;
>
> 	mixin funcWithAttr!("auto opSlice()", safetyOn ? "@safe" : "", q{
> 		return Range(data, 0, data.length);
> 	});
> }

Really?

On Saturday, 19 August 2017 at 13:09:41 UTC, Nicholas Wilson wrote:
>
> Hacking the runtime is certainly one way to achieve changing the default attributes.
> However having them as regular attributes means that is is possible to do configuration by version statements, which is a) much easier than hacking the runtime and b) causes much less fragmentation.
>

This may not be so elegant...but what if one could only take an alias of these in core.attributes or in a package.d file? At least that way people would know where to look if widespread changes are made?

On Saturday, 19 August 2017 at 17:10:54 UTC, bitwise wrote:
> I'm still concerned about having to read code that's laced full of custom attributes, the resolution of which may span several files, templates, etc.
>
> I also think this type of thing could have a detrimental effect on modularity when you end up having to include "myAttribs.d" in every single file you want to work on. I would much rather have a flexible in-language solution, or a solution that didn't require me to define my own attributes.

Having worked on a project with a lot of attributes, my suggestion would be to import it via a package.d, you'll be importing that anyway.

On Saturday, 19 August 2017 at 19:15:25 UTC, bitwise wrote:
> On Saturday, 19 August 2017 at 18:22:58 UTC, Guillaume Boucher wrote:
>> On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
>>> In a high-performance context though, the performance hit may be unacceptable.
>>
>> Well in those super rare situations, there's always the workaround with mixins:
>
> Those situations are not rare.
>
>> mixin template funcWithAttr(string decl, string attributes, string code) {
>>     pragma(msg, "<<<" ~ code ~ ">>>");
>>     mixin(decl ~ attributes ~ "{" ~ code ~" }");
>> }
>>
>> struct Container(T, bool safetyOn = true)
>> {
>> 	static if(safe)
>> 		RefCounted!(T[]) data;
>> 	else
>> 		T[] data;
>>
>> 	mixin funcWithAttr!("auto opSlice()", safetyOn ? "@safe" : "", q{
>> 		return Range(data, 0, data.length);
>> 	});
>> }
>
> Really?

With DIP 1012 you should be able to go

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

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

 template safeIf(bool cond)
 {
     static if (cond) alias safeIf = AliasSeq!(safe);
     else                   alias safeIf = AliasSeq!();
 }

or even just

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

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

Container!int foo; // Container!(int, safe)
Container!(int, system) bar;

The only downside is that the second form leaves itself open to
Container!(int, trusted) quux;
which is probably undesirable.

On Saturday, 19 August 2017 at 20:39:07 UTC, jmh530 wrote:
> On Saturday, 19 August 2017 at 13:09:41 UTC, Nicholas Wilson wrote:
>>
>> Hacking the runtime is certainly one way to achieve changing the default attributes.
>> However having them as regular attributes means that is is possible to do configuration by version statements, which is a) much easier than hacking the runtime and b) causes much less fragmentation.
>>
>
> This may not be so elegant...but what if one could only take an alias of these in core.attributes or in a package.d file? At least that way people would know where to look if widespread changes are made?

Sorry, I was referring to preconfigurations in druntime like
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60

On Sunday, 20 August 2017 at 00:49:28 UTC, Nicholas Wilson wrote:
>
> [...]
>
> With DIP 1012 you should be able to go
>
>  struct Container(T, bool safetyOn = true)
>  {
>  	static if(safe)
>  		RefCounted!(T[]) data;
>  	else
>  		T[] data;
>
>  	auto opSlice() @safeIf!safetyOn {
>  		return Range(data, 0, data.length);
>  	}
>  }
>
>  template safeIf(bool cond)
>  {
>      static if (cond) alias safeIf = AliasSeq!(safe);
>      else                   alias safeIf = AliasSeq!();
>  }
>
> or even just
>
>  struct Container(T, FunctionSafety safetyOn = safe)
>  {
>  	static if(safe)
>  		RefCounted!(T[]) data;
>  	else
>  		T[] data;
>
>  	auto opSlice() @safetyOn {
>  		return Range(data, 0, data.length);
>  	}
>  }
>
> Container!int foo; // Container!(int, safe)
> Container!(int, system) bar;

This is indeed, a nice solution. I am a _bit_ worried about abuse, and loss of modularity, but aside from that, I think it's a better solution overall.

> The only downside is that the second form leaves itself open to

Easily fixed with a template constraint, right?


This could potentially render a large portion of the projects on code.dlang.org broken though. What would be nice, is if code.dlang.org regularly built all the projects, and notified the authors of the breakage, possibly sending a list of recent compiler changes as well.

On Sunday, 20 August 2017 at 01:05:39 UTC, bitwise wrote:
> This is indeed, a nice solution. I am a _bit_ worried about abuse, and loss of modularity, but aside from that, I think it's a better solution overall.

All features in the style of "I know what I'm doing, just let me do it!" (=void, @trusted ect.) are open to abuse but I don't think we've ever had problems with them. They tend to be used sparingly and only when absolutely necessary.

 I'm not quite sure how this would lead to a loss of modularity?

>> The only downside is that the second form leaves itself open to
>
> Easily fixed with a template constraint, right?

True, too early in the morning. zzz.

> This could potentially render a large portion of the projects on code.dlang.org broken though. What would be nice, is if code.dlang.org regularly built all the projects, and notified the authors of the breakage, possibly sending a list of recent compiler changes as well.

I don' think It would break too much, but we have @future to mitigate all potential breakages from this DIP. Autotesting is obviously desirable.

On Sunday, 20 August 2017 at 00:55:41 UTC, Nicholas Wilson wrote:
>
> Sorry, I was referring to preconfigurations in druntime like
> https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60

So modifying core.attribute.defaultAttributeSet in the runtime is the only way to change the default attribute set, but one could create a custom attribute that they just use as needed. So one could just look at the top of the file to see if the code has something like @myDefaultAttributeSet.

On Sunday, 20 August 2017 at 02:53:14 UTC, jmh530 wrote:
> On Sunday, 20 August 2017 at 00:55:41 UTC, Nicholas Wilson wrote:
>>
>> Sorry, I was referring to preconfigurations in druntime like
>> https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60
>
> So modifying core.attribute.defaultAttributeSet in the runtime is the only way to change the default attribute set,

Yes, whether that be a custom runtime or through version conditions that define core.attribute.defaultAttributeSet.

>but one
> could create a custom attribute that they just use as needed. So one could just look at the top of the file to see if the code has something like @myDefaultAttributeSet.

Yes. Hopefully a bit more descriptive though ;)