"Walter Bright" wrote in message news:[email protected]...
> I have std.simd sitting here, and I really want to finish it, but I
> still don't have the tools to do so.
> I need, at least, forceinline to complete it, but that one *is*
> controversial - we've talked about this for years.
I proposed a DIP to fix that, but it could not get reasonable consensus.
http://wiki.dlang.org/DIP56
You did, after all, convince me that we need an "always inline" and a
"never inline" method.
From the DIP:
If a pragma specifies always inline, whether or not the target function(s)
are actually inlined is
implementation defined, although the implementation will be expected to
inline it if practical.
Implementations will likely vary in their ability to inline.
I expect a proposal in which 'always' means "inline or give an error" would
be much better received.
The thing is, I don't understand *why* you want to wrangle storage
classes. What is the coding pattern?
That's the wrong question. I could ask "why do you hate ref as a storage
class"?
I suspect the answer is that sometimes it is useful to ensure some
parameters are passed by reference, not by value. With ref as a type, this
would be trivial:
template MyParamType(T)
{
static if (someCriteria!T)
alias MyParamType = ref(T);
else
alias MyParamType = T;
}
void myFunction(T, U, V)(const MyParamType!T, const MyParamType!U, const
MyParamType!V)
{
...
}
