On 12/03/2015 10:29 PM, Andrei Alexandrescu wrote:
>
> FWIW I wanted to use it to allow lst.linear.stable.insert() and
> lst.stable.linear.insert() to refer to the same function, but this is
> not working. Qualifies as a bug?

Yes. (It works with my own implementation of name lookup.)

On 12/03/2015 08:52 PM, Tofu Ninja wrote:
> On Friday, 4 December 2015 at 01:09:07 UTC, Andrei Alexandrescu wrote:
>> On 12/03/2015 08:04 PM, Idan Arye wrote:
>>> People are going to hate me, but http://dpaste.dzfl.pl/851d1d1f5e4b
>>
>> Win :o). -- Andrei
>
> Not win, we should feel ashamed that this is the kind of stuff you have
> to do.

I'm running out of shame over here. -- Andrei

On 12/03/2015 08:59 PM, Steven Schveighoffer wrote:
> On 12/3/15 8:01 PM, Andrei Alexandrescu wrote:
>> On 12/03/2015 05:59 PM, Steven Schveighoffer wrote:
>>>
>>> alias stableLinearXxx = linearStableXxx;
>>
>> Doesn't scale. -- Andrei
>
> To what? How many nested namespaces are you planning?

Many functions, not many namespaces. One declaration per function is fail. -- Andrei

On Friday, 4 December 2015 at 02:02:48 UTC, Timon Gehr wrote:
> On 12/04/2015 02:37 AM, Mike wrote:
>> On Friday, 4 December 2015 at 01:04:33 UTC, Idan Arye wrote:
>>>
>>> People are going to hate me, but http://dpaste.dzfl.pl/851d1d1f5e4b
>>
>> Doesn't seem to scale to member access: http://dpaste.dzfl.pl/37193377524c
>>
>> /d649/f987.d-mixin-3(7): Error: 'this' is only defined in non-static
>> member functions, not fun
>>
>> Is there a way to make it work?
>>
>> Mike
>
> template namespace(string code,alias a=void){
>     mixin(code);
> }
>
> struct List{
>     int x;
>     alias stable = namespace!(q{
>         void fun(){
>             import std.stdio;
>             writeln(this.x);
>         }
>     },x);
> }
>
> void main(){
>     List lst;
>     lst.stable.fun();
> }
>
>
> :o)

WTF! Why does that even work! That is strait madness! When the code gets mixed into the namespace template, x would have been re-aliased to a, it would have made sense to write "writeln(a)" which works as well... but "writeln(this.x)", wut, how... that makes no sense...

On Friday, 4 December 2015 at 02:24:32 UTC, Tofu Ninja wrote:
> On Friday, 4 December 2015 at 02:02:48 UTC, Timon Gehr wrote:
>> On 12/04/2015 02:37 AM, Mike wrote:
>>> On Friday, 4 December 2015 at 01:04:33 UTC, Idan Arye wrote:
>>>>
>>>> People are going to hate me, but http://dpaste.dzfl.pl/851d1d1f5e4b
>>>
>>> Doesn't seem to scale to member access: http://dpaste.dzfl.pl/37193377524c
>>>
>>> /d649/f987.d-mixin-3(7): Error: 'this' is only defined in non-static
>>> member functions, not fun
>>>
>>> Is there a way to make it work?
>>>
>>> Mike
>>
>> template namespace(string code,alias a=void){
>>     mixin(code);
>> }
>>
>> struct List{
>>     int x;
>>     alias stable = namespace!(q{
>>         void fun(){
>>             import std.stdio;
>>             writeln(this.x);
>>         }
>>     },x);
>> }
>>
>> void main(){
>>     List lst;
>>     lst.stable.fun();
>> }
>>
>>
>> :o)
>
> WTF! Why does that even work! That is strait madness! When the code gets mixed into the namespace template, x would have been re-aliased to a, it would have made sense to write "writeln(a)" which works as well... but "writeln(this.x)", wut, how... that makes no sense...

WTF, some how having an alias to x passed in, brings the entire this along with it. This works equally as well....

struct List{
	int x;
	int y;
	alias stable = namespace!(q{
			void fun(){
				import std.stdio;
				writeln(typeid(this));
                                writeln(this.x + this.y);
			}
		},x);
}

On 12/04/2015 03:24 AM, Tofu Ninja wrote:
> On Friday, 4 December 2015 at 02:02:48 UTC, Timon Gehr wrote:
>> On 12/04/2015 02:37 AM, Mike wrote:
>>> On Friday, 4 December 2015 at 01:04:33 UTC, Idan Arye wrote:
>>>>
>>>> People are going to hate me, but http://dpaste.dzfl.pl/851d1d1f5e4b
>>>
>>> Doesn't seem to scale to member access:
>>> http://dpaste.dzfl.pl/37193377524c
>>>
>>> /d649/f987.d-mixin-3(7): Error: 'this' is only defined in non-static
>>> member functions, not fun
>>>
>>> Is there a way to make it work?
>>>
>>> Mike
>>
>> template namespace(string code,alias a=void){
>>     mixin(code);
>> }
>>
>> struct List{
>>     int x;
>>     alias stable = namespace!(q{
>>         void fun(){
>>             import std.stdio;
>>             writeln(this.x);
>>         }
>>     },x);
>> }
>>
>> void main(){
>>     List lst;
>>     lst.stable.fun();
>> }
>>
>>
>> :o)
>
> WTF! Why does that even work! That is strait madness! When the code gets
> mixed into the namespace template, x would have been re-aliased to a, it
> would have made sense to write "writeln(a)" which works as well... but
> "writeln(this.x)", wut, how... that makes no sense...

http://dlang.org/spec/template.html#nested-templates

"If a template has a template alias parameter, and is instantiated with a local symbol, the instantiated function will implicitly become nested in order to access runtime data of the given local symbol."

You are probably relying on this feature in a significant portion of your code, especially for lambda template arguments. It does not really cover all cases where one would like to have nested instantiation though.

On 12/3/15 9:20 PM, Andrei Alexandrescu wrote:
> On 12/03/2015 08:59 PM, Steven Schveighoffer wrote:
>> On 12/3/15 8:01 PM, Andrei Alexandrescu wrote:
>>> On 12/03/2015 05:59 PM, Steven Schveighoffer wrote:
>>>>
>>>> alias stableLinearXxx = linearStableXxx;
>>>
>>> Doesn't scale. -- Andrei
>>
>> To what? How many nested namespaces are you planning?
>
> Many functions, not many namespaces. One declaration per function is
> fail. -- Andrei

It seems worse with namespaces:

1. a linear namespace
2. a sub namespace for linear.stable
3. a function definition for linear.stable.foo
4. a stable namespace
5. a sub namespace for stable.linear
6. an alias (I'm assuming you're not repeating the function definition here) for stable.linear.foo to linear.stable.foo

Perhaps my strawman isn't what you were thinking, let me know. It appears to me that you will need more machinery for namespaces.

-Steve

On 12/03/2015 09:37 PM, Steven Schveighoffer wrote:
> On 12/3/15 9:20 PM, Andrei Alexandrescu wrote:
>> On 12/03/2015 08:59 PM, Steven Schveighoffer wrote:
>>> On 12/3/15 8:01 PM, Andrei Alexandrescu wrote:
>>>> On 12/03/2015 05:59 PM, Steven Schveighoffer wrote:
>>>>>
>>>>> alias stableLinearXxx = linearStableXxx;
>>>>
>>>> Doesn't scale. -- Andrei
>>>
>>> To what? How many nested namespaces are you planning?
>>
>> Many functions, not many namespaces. One declaration per function is
>> fail. -- Andrei
>
> It seems worse with namespaces:
>
> 1. a linear namespace
> 2. a sub namespace for linear.stable
> 3. a function definition for linear.stable.foo
> 4. a stable namespace
> 5. a sub namespace for stable.linear
> 6. an alias (I'm assuming you're not repeating the function definition
> here) for stable.linear.foo to linear.stable.foo
>
> Perhaps my strawman isn't what you were thinking, let me know. It
> appears to me that you will need more machinery for namespaces.
>
> -Steve

I don't get your point. Mine is there are many methods and few named scopes aka namespaces. So I'm okay to scale declarations linearly with number of named scopes but not with number of methods. -- Andrei

On 12/3/15 9:40 PM, Andrei Alexandrescu wrote:
> On 12/03/2015 09:37 PM, Steven Schveighoffer wrote:
>> On 12/3/15 9:20 PM, Andrei Alexandrescu wrote:
>>> On 12/03/2015 08:59 PM, Steven Schveighoffer wrote:
>>>> On 12/3/15 8:01 PM, Andrei Alexandrescu wrote:
>>>>> On 12/03/2015 05:59 PM, Steven Schveighoffer wrote:
>>>>>>
>>>>>> alias stableLinearXxx = linearStableXxx;
>>>>>
>>>>> Doesn't scale. -- Andrei
>>>>
>>>> To what? How many nested namespaces are you planning?
>>>
>>> Many functions, not many namespaces. One declaration per function is
>>> fail. -- Andrei
>>
>> It seems worse with namespaces:
>>
>> 1. a linear namespace
>> 2. a sub namespace for linear.stable
>> 3. a function definition for linear.stable.foo
>> 4. a stable namespace
>> 5. a sub namespace for stable.linear
>> 6. an alias (I'm assuming you're not repeating the function definition
>> here) for stable.linear.foo to linear.stable.foo
>>
>> Perhaps my strawman isn't what you were thinking, let me know. It
>> appears to me that you will need more machinery for namespaces.
>>
>
> I don't get your point. Mine is there are many methods and few named
> scopes aka namespaces. So I'm okay to scale declarations linearly with
> number of named scopes but not with number of methods. -- Andrei
>

I think I see, all you need is a way to generate the aliases that will be both linear and stable. I can think of nasty ways to do this with opDispatch.

FWIW, I don't believe this complexity of API is worth it. It may be you have all this wonderful mechanisms to specify exactly the runtime requirements for your algorithms -- and nobody uses it because they either a) have a specific container in mind, or b) don't care to constrain the container type being used. I think there are a few basic guarantees to worry about, and anything beyond that is overcomplicating things.

-Steve

On 12/03/2015 09:59 PM, Steven Schveighoffer wrote:
> FWIW, I don't believe this complexity of API is worth it.

It's essential. -- Andrei