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.
