DIP1028 - Rationale for accepting as is

[Johannes Loher]

On Sunday, 24 May 2020 at 12:14:13 UTC, aliak wrote:
> On Sunday, 24 May 2020 at 11:30:53 UTC, Johannes Loher wrote:
>> On Sunday, 24 May 2020 at 11:25:06 UTC, aliak wrote:
>>> On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
>>>> does not work). But I admit that it is still a bit weird to 
>>>> have 2 different defaults.
>>>
>>> Is that any more or less weirder than having functions 
>>> inferred with different attributes based on context?
>>
>> What exactly are you referring to?
>
> Attribute inference by D, specifically template functions. The 
> attributes are inferred based on context (I don't know the 
> exact algorithm). So a function f(T)(T) when called can maybe 
> be pure, maybe safe, maybe not?

 From what I understand, it does not depend on the context but on 
the template parameters you pass to the template. I agree that it 
might be a bit confusing at first, but it makes sense if you 
realize that templates themselves are not functions but something 
that can generate functions (and other constructs) from compile 
time parameters. Why shouldn't the attributes of a generated 
function be able to depend on the parameters being passed to the 
template? Basically everything else can depend on them, too. 
Automatically inferring the attributes is just a very convenient 
way to do that. But yeah, it's not 100% consistent that they are 
not also inferred for regular functions (some people have been 
arguing for that).

However, at least for templates, there is a very good reason for 
the difference (or at least the fact that attributes are inferred 
for templates): if that was not the case, it would basically be 
impossible to write generic code that works with all the 
attribute combinations. However, the very purpose of templates is 
to enable writing generic code. They wouldn't make that much 
sense if that capability was strongly limited.

On the other hand, having different @safety defaults for bodiless 
function declarations and regular faction declarations does not 
have such a big benefit, especially when considering the fact, 
that we can have the same defaults but make @safe (default or 
explicit) bodiless function declarations a compiler error. If we 
ignore that option for some reason, it would only be dort of a 
necessity in order to prevent people from shooting them selves in 
the foot without even noticing. But there is no inherent value in 
the difference, it doesn't enable anything.

That said, I'd still prefer this variant over what DIP1028 does 
currently. It's just that I think the other option is even better 
because it is more consistent.