On 9/28/14, 5:38 PM, Manu via Digitalmars-d wrote:
I was out of town (was on my phone), and now I'm home with 2 guests,
and we're working together. I can't sit and craft a pile of example
cases until I'm alone and have time to do so. I haven't ignored it,
but I need to find the time to give you what you want.
Thanks, don't feel under any obligation express or implied to follow
through.
That said, my friend encountered one of my frequently recurring pain
cases himself yesterday:
struct S(T...)
{
void f(T args) {}
}
S!(int, ref S) fail; // <-- no clean way to do this. I need this very
frequently, and he reached for it too, so I can't be that weird.
I understand. The short answer to this is D cannot do that and we cannot
afford to change the language to make it do that.
There are two longer answers.
The first longer answer is there are ways to do that if it's a
necessity, as you know and probably did. I agree it's not clean/easy.
The second longer answer is if you do this it means you're trying to
write C++ in D: in C++ ref is part of the type (well... sort of) and
therefore someone coming from C++ and translating the respective designs
into D will find the change frustrating.
I've seen this pattern several times. Most recent was in conjunction
with iterators vs. ranges. There's discussion going on in C++ circles
about adding ranges to C++. One common issue raised by people gravitates
around designs where the choice of using iterators is long foregone, and
would think that replacing iterators with ranges throughout should just
work. Take a look:
http://article.gmane.org/gmane.comp.lib.boost.devel/191978
The reality is algorithms implemented with ranges look different from
algorithms implemented with iterators. Similarly, generic code with D
will look different from generic code with C++. Our hope is, of course,
that all told range-based and D-generics code has advantages going for
it, but the most dramatic of those advantages most certainly won't be
discovered and reaped in designs that are copies of the respective C++ ones.
So you can't be that weird and neither is your friend, but I speculate
that both of you have a solid C++ background :o).
About this situation in particular, yes, ref being part of the type does
help this declaration, but overall as a design decision for the C++
programming value its value is questionable. T& is not a first class
type and that hurts everyone everywhere - you can't create a value of
that types, and virtually all parts of the language have special rules
telling what happens when the actual type is a reference type. I think
Walter made the right call here and we shouldn't change anything.
Andrei
