Local functions infer attributes?

[Manu via Digitalmars-d]

On 29 September 2014 12:43, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 9/28/2014 6:31 PM, Manu via Digitalmars-d wrote:
>>>
>>>    S!(int, S*)
>>
>> That's different.
>>
>> I feel like I have to somehow justify to you guys how meta code works
>> in D. I have meta code that is no less than 5 layers deep. It's
>> complex, but at the same time, somehow surprisingly elegant and simple
>> (this is the nature of D I guess).
>> If I now assume throughout my meta "pointer means ref", then when I
>> actually pass a pointer in, the meta can't know if it was meant to be
>> a ref or not. It results in complex explicit logic to handle at almost
>> every point due to a loss of information.
>>
>> You can't call f() with the same syntax anymore (you need an '&')
>> which is a static if in the meta, you can't use the S* arg in the same
>> meta (needs a '*') which is another static if. Assignments are
>> changed, and unexpected indexing mechanics appear. When implementation
>> logic expects and understands the distinction between pointers and
>> ref's, this confuses that logic. When I interface between languages
>> (everything I never do binds to at least C++, and in this case, also
>> Lua), this complicates the situation.
>>
>> I can't conflate 2 things that aren't the same. It leads to a lot of
>> mess in a lot of places.
>
>
> You're right that tuples in D cannot contain storage classes (and ref is
> just one storage class, there's also out and in, etc.).

I know, that's my whole point. I think 'storage class' is the original sin.
in is declared as scope const, or in my fantasy world scope(const(T)).

out is the only interesting storage class (conceptually) I've used. It
is effectively just an alias for ref, but it also encodes some special
non-type information, which is to initialise prior to the call.


> You can use autoref, but I haven't understood why that doesn't work for you.

I'm not writing java or python code here. I consider it a fundamental
quality of a 'systems language', or perhaps just a native language,
that I have the explicit power to produce binary I intend.
I can't have the compiler deciding if something is to be ref or not.
My code is rarely only consumed by other D code. I have lots of cross
language linkage, and also dynamic libraries (which expect a specific
ABI).

auto ref wouldn't work in that situation I gave above anyway...
S!(auto ref T) is no more valid than S!(ref T).