Weird template error

Nick Sabalausky a at a.a
Wed Nov 26 13:07:09 PST 2008


"Jarrett Billingsley" <jarrett.billingsley at gmail.com> wrote in message 
news:mailman.61.1227711020.22690.digitalmars-d at puremagic.com...
> On Wed, Nov 26, 2008 at 8:12 AM, Nick Sabalausky <a at a.a> wrote:
>> Another idea, but possibly messy:
>> Maybe there could be some automatic behind-the-scenes
>> templatization/overloading such that: If there's a function ("bar") that 
>> has
>> a parameter passed by reference ("x"), and you try to pass "bar" a 
>> property
>> (of the correct type), then an overloaded version of "bar" is created 
>> which
>> replaces accesses to x with calls to x's getter/setter.
>>
>> Ie:
>>
>> void bar(inout int x)
>> {
>>    x = x + 2;
>> }
>>
>> void main()
>> {
>>   int i;
>>   auto foo = new Foo();
>>   bar(i);
>>
>>   bar(foo.x);
>>   // When the compiler detects the above line,
>>   // it generates the following overload of bar:
>> }
>>
>> // Automatically generated by compiler,
>> // unless "bar(foo.x);" above is commented out.
>> void bar(inout property!(int) x)  // "property!(T)" is either built-in or
>> part of the core library
>> {
>>    x.setter(x.getter() + 2);
>> }
>>
>> Although, I suppose that might still create an excess of extra functions
>> when using dynamically-linked libraries (or maybe not, because it would
>> probably only be needed on inout params, and I don't think it's common to
>> have a large number of those).
>
> It would also make it difficult to have virtual methods with ref
> parameters, since the compiler might have to generate 2 ^ (num ref
> params) overloads of each such method.

But how often are "inout" params really used anyway? Plus, unless there's 
dynamic library loading going on, it would only have to generate the ones 
that are actually used.

I still prefer my original suggestion though. This is just in the case that 
my original suggestion turns out to have problems that realistically crop up 
even when not abusing property syntax. 





More information about the Digitalmars-d mailing list