https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #20 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-01-24 08:55:12 EET ---
(In reply to comment #19)
> Maybe you're misunderstanding the effect of 'static' attribute. As far as I know, it means that:

I think I understand how it works now. But I don't think this is how it SHOULD work, because it is not intuitive. No other programming language does this, and no one expects it to act like this. So I think it is a limitation imposed by implementation detail that needs to be fixed.

> Even if it will become possible in the future, but currently it isn't. I have no opinion about non existing feature.

I hope it will be fixed, I think this is an important issue. Maybe Facebook will place a nice bounty in the next round :)

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #21 from Kenji Hara <k.hara.pg@gmail.com> 2014-01-23 23:33:10 PST ---
(In reply to comment #20)
> (In reply to comment #19)
> > Maybe you're misunderstanding the effect of 'static' attribute. As far as I know, it means that:
> 
> I think I understand how it works now. But I don't think this is how it SHOULD work, because it is not intuitive. No other programming language does this, and no one expects it to act like this. So I think it is a limitation imposed by implementation detail that needs to be fixed.

I think it is enough reasonable definition because:
1. Currently dmd works that way.
2. It is consistent definition and allow such the code in comment#1.

Anyway, can you agree that the OP code needs fixup with 2.065 and this issue should me marked as INVALID?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #22 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-01-24 09:40:21 EET ---
No, I do not agree that this bug is INVALID. It is still a regression, and I maintain that the current behavior and your suggested workaround are illogical.

> 1. Currently dmd works that way.

This is not a good argument - if it works in a wrong way, it needs to be fixed.

> 2. It is consistent definition and allow such the code in comment#1.

It shouldn't be required to either use "static" or put the function in a template block.

Anyway, I understand if this is a very complicated problem that is not worth stopping the release for, so I would agree with a WONTFIX (or REMIND/LATER?) resolution. But I think it would be good to hear someone else's opinion in this discussion first.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #23 from Walter Bright <bugzilla@digitalmars.com> 2014-01-26 12:31:01 PST ---
> This just shows another bug - that you still need "static" (which makes NO
sense for a free function, templated or not), but now you must hide it inside a template!

I agree.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #24 from Walter Bright <bugzilla@digitalmars.com> 2014-01-26 12:46:49 PST ---
Some thoughts:

1. 'static' in D has come to mean "a context pointer is not supplied". For example, in C:

    void foo() {
       static int x;
    }

x can be accessed without the "context pointer", in this case the stack pointer. Static doesn't mean it is unnested or global.

2. Alias template arguments are never "passed" to a template in the way that arguments are passed to functions. They simply make the symbol in scope in the template body.

3. Static as an attribute makes no sense in a context where there is no context pointer. I.e. declarations at global level, declarations inside global templates, etc.

4. A use of a symbol, where that use does not require a context pointer, should not issue an error if a context pointer is not supplied.

5. I don't think we're going to resolve this easily without a lot of careful thought.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #25 from Walter Bright <bugzilla@digitalmars.com> 2014-01-26 12:51:42 PST ---
I suspect this should work:

  int f(alias A)() { return 0; }
  struct S { int x; enum y = f!x(); }

whereas this should not:

  int f(alias A)() { return A; }
  struct S { int x; enum y = f!x(); }

i.e. this check:

  foo3.d(1): Error: function foo3.S.f!(x).f need 'this' to access member f

should not be done for arguments to template alias parameters.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #26 from Kenji Hara <k.hara.pg@gmail.com> 2014-01-29 18:23:31 PST ---
(In reply to comment #24)
> Some thoughts:
> 
> 1. 'static' in D has come to mean "a context pointer is not supplied". For example, in C:
> 
>     void foo() {
>        static int x;
>     }
> 
> x can be accessed without the "context pointer", in this case the stack pointer. Static doesn't mean it is unnested or global.

I used the word 'unnested' to represent the equivalent meaning with "a context pointer is not supplied". So basically I agree with this.

> 2. Alias template arguments are never "passed" to a template in the way that arguments are passed to functions. They simply make the symbol in scope in the template body.

About the merely visibility of the passed alias parameter, it is correct.
But, instantiated function f!(x).f should have a context to access context-full
symbol 'x'. _Currently_ this is not avoidable.

> 3. Static as an attribute makes no sense in a context where there is no context pointer. I.e. declarations at global level, declarations inside global templates, etc.

Yes.

> 4. A use of a symbol, where that use does not require a context pointer, should not issue an error if a context pointer is not supplied.

Essentially yes. But current compiler does not support the principle, because of the lack of language feature.

> 5. I don't think we're going to resolve this easily without a lot of careful thought.

Definitely yes.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #27 from Kenji Hara <k.hara.pg@gmail.com> 2014-01-29 18:28:07 PST ---
(In reply to comment #25)
> I suspect this should work:
> 
>   int f(alias A)() { return 0; }
>   struct S { int x; enum y = f!x(); }
> 
> whereas this should not:
> 
>   int f(alias A)() { return A; }
>   struct S { int x; enum y = f!x(); }
> 
> i.e. this check:
> 
>   foo3.d(1): Error: function foo3.S.f!(x).f need 'this' to access member f
> 
> should not be done for arguments to template alias parameters.

Currently this is necessary.

As a technical talk, in current semantic analysis system, the "context-ness" of a function - whether a function really needs a context or not - should be determined without its body analysis. As far as I see, current dmd code relies on the assumption.

To relax the limitation, we should infer the context-ness as same as attribute inference, but it should be considered as a new language enhancement but it is not definitely so small.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #28 from Kenji Hara <k.hara.pg@gmail.com> 2014-01-29 18:44:24 PST ---
On the other hand, the purpose of issue 11533 is simple and consistent.

If a module level declaration is moved into function/aggreage scope with additional 'static' attribute, it should have exactly same behavior.

Examples:

module a;
int var;
void foo();
class C {}
void bar(T)(T) {}
struct S(alias pred) { void f() {} }
void baz(alias v)(T) { v = 1; }

class Test {
    static int var;
    static void foo();
    static class C {}
    static void bar(T)(T) {}
    static struct S(alias pred) { void f() {} }  // New!
    static void baz(alias v)(T) { v = 1; }  // New!
}
void test() {
    static int var;
    static void foo();
    static class C {}
    static void bar(T)(T) {}
    static struct S(alias pred) { void f() {} }  // New!
    static void baz(alias v)(T) { v = 1; }  // New!
}

The case of 'S' and 'baz' are newly supported by fixing 11533.
- S(alias pred) will become context-free if 'pred' is context-free.
- baz(alias v) will become context-free if 'v' is context-free.

Indeed, to support baz case current 'static' attribute semantics is made a
little complex, but the introduced behavior is simple, consistent, and easy
understandable.
I think fixiing 11533 is a huge win for the D code locality.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946


Dicebot <public@dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public@dicebot.lv


--- Comment #29 from Dicebot <public@dicebot.lv> 2014-03-03 07:42:12 PST ---
I agree with Vladimir here. This is basically replacing one hack with another so that both code will break and no desired solution will be introduced. Such change can't be justified and this supposed win is imaginary.

About anything that legitimates statement "templated free function is not a free function" is a huge "NO!" in my opinion.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------