internal/local template memebers

Bill Baxter wbaxter at gmail.com
Sat Oct 25 06:10:08 PDT 2008


On Sat, Oct 25, 2008 at 10:08 PM, Bill Baxter <wbaxter at gmail.com> wrote:
> On Sat, Oct 25, 2008 at 8:48 PM, Denis Koroskin <2korden at gmail.com> wrote:
>> On Sat, 25 Oct 2008 08:05:41 +0400, BCS <ao at pathlink.com> wrote:
>>
>>> A number of times while working with template code I have found that I
>>> need a variable inside a template but don't want the side effects of doing
>>> so. Specifically 1) having a tmp variable results in having to explicitly
>>> reference template members rather than being able to use the default member
>>> rule and 2) the extra symbols seem to result in a substantial increases in
>>> the compile time memory usage.
>>>
>>> The idea I'm floating would be to have a "local" storage class (or
>>> whatever keyword is chosen) that would only be accessible from within the
>>> template it is declared in:
>>>
>>>
>>> template Foo(char[] str)
>>> {
>>>    local char[] first = str[0..$/2];
>>>    local char[] last = str[$/2..$];
>>>
>>>    const char[] Foo = Foo!(first) ~ Foo!(last); // legal; note not
>>> "Foo!().Foo"
>>>    // const char[] Foo = Foo!(first).a ~ Foo!(last).a; // error a is not
>>> accessible
>>> }
>>>
>>> During compilation these variables would be computed, used and thrown away
>>> resulting in no long term memory cost.
>>>
>>>
>>
>>
>> I agree! But I would prefer re-using public/private - they make perfect
>> sense here - instead of new internal/local keywords.
>
> Problem is templates can be mixed in.  And in that case public/private
> has meaning in the context of the host.

...But contextual keywords to the rescue!

   private(local) char[] first = str[0..$/2];
   private(local) char[] last = str[$/2..$];

--bb



More information about the Digitalmars-d mailing list