Local functions infer attributes?

[Andrei Alexandrescu via Digitalmars-d]

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