internal/local template memebers

KennyTM~ kennytm at gmail.com
Sat Oct 25 06:39:27 PDT 2008


Bill Baxter wrote:
> 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

Sweet, suddenly contextual keywords become a viable solution to 
everything; first the new member functions, now this :). Why no one had 
suggested it before?

(Although private(local) sounds like unnecessary redundancy here.)



More information about the Digitalmars-d mailing list