On Monday, March 11, 2013 23:12:45 monarch_dodra wrote:
> What *are* you talking about??? I can count 4 declarations in 2 static ifs? What is your definition of "declaration" and "scope".
> 
> There's a misunderstanding somewhere here. Can YOU show us an example where there is a declaration that is scoped?

Exactly. Every single line in those static ifs is a variable declaration, and not a one of them creates a new scope, or the code wouldn't compile. I don't understand how Timon can think that there are no declarations in that code. There's clearly a fundamental misunderstanding and/or miscommunication here.

- Jonathan M Davis

On 3/12/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> There's clearly a fundamental misunderstanding

Clearly 10 people in here haven't read his sentence properly where he said "in the static if **condition**", and not the static if *block*.

On Mon, 11 Mar 2013 20:53:59 -0400
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote:

> On Monday, March 11, 2013 23:12:45 monarch_dodra wrote:
> > What *are* you talking about??? I can count 4 declarations in 2 static ifs? What is your definition of "declaration" and "scope".
> > 
> > There's a misunderstanding somewhere here. Can YOU show us an example where there is a declaration that is scoped?
> 
> Exactly. Every single line in those static ifs is a variable declaration, and not a one of them creates a new scope, or the code wouldn't compile. I don't understand how Timon can think that there are no declarations in that code. There's clearly a fundamental misunderstanding and/or miscommunication here.
> 

Timon was talking about declarations in the static if's *condition*, not the body.

On Mon, Mar 11, 2013 at 09:03:20PM -0400, Nick Sabalausky wrote:
> On Mon, 11 Mar 2013 20:53:59 -0400
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
> 
> > On Monday, March 11, 2013 23:12:45 monarch_dodra wrote:
> > > What *are* you talking about??? I can count 4 declarations in 2 static ifs? What is your definition of "declaration" and "scope".
> > > 
> > > There's a misunderstanding somewhere here. Can YOU show us an example where there is a declaration that is scoped?
> > 
> > Exactly. Every single line in those static ifs is a variable declaration, and not a one of them creates a new scope, or the code wouldn't compile. I don't understand how Timon can think that there are no declarations in that code. There's clearly a fundamental misunderstanding and/or miscommunication here.
> > 
> 
> Timon was talking about declarations in the static if's *condition*, not the body.

Regardless, I have shown that even declarations in the condition leaks past the body of the static if.


T

-- 
Don't modify spaghetti code unless you can eat the consequences.

On Monday, 11 March 2013 at 22:42:26 UTC, Era Scarecrow wrote:
> On Monday, 11 March 2013 at 21:31:53 UTC, Timon Gehr wrote:
>> On 03/11/2013 09:19 PM, Jonathan M Davis wrote:
>>> On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
>>>> Actually, in D, static if creates its own scopes for declarations made
>>>> inside the static if condition.
>>>
>>> No, it doesn't,
>>
>> Yes it does.
>
> No, it doesn't.
>
>>> and it would be _way_ less useful if it did,
>>
>> I don't think so.
>
>  Oh? Examples inside the TDPL would break as the inner scopes would be hidden and thereby inaccessible.
>

Good, now check the meaning of condition.

On Tuesday, 12 March 2013 at 00:54:18 UTC, Jonathan M Davis wrote:
> On Monday, March 11, 2013 23:12:45 monarch_dodra wrote:
>> What *are* you talking about??? I can count 4 declarations in 2
>> static ifs? What is your definition of "declaration" and "scope".
>> 
>> There's a misunderstanding somewhere here. Can YOU show us an
>> example where there is a declaration that is scoped?
>
> Exactly. Every single line in those static ifs is a variable declaration, and
> not a one of them creates a new scope, or the code wouldn't compile. I don't
> understand how Timon can think that there are no declarations in that code.
> There's clearly a fundamental misunderstanding and/or miscommunication here.
>
> - Jonathan M Davis

Yes, you totally missed the point where he was saying in *condition*

On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu wrote:

> Wow. That's quite out of character for Bjarne. I think it's quite a poor piece.
>
> Andrei

I simply didn't have the stomach to read it after the first paragraph. They have no idea what they are talking about. It is as if they never used templates more than writing one liners. Harder to read, understand, debug? I am just speechless.

On Saturday, 9 March 2013 at 16:42:56 UTC, deadalnix wrote:
> On Saturday, 9 March 2013 at 15:22:55 UTC, monarch_dodra wrote:
>> [..]
>> BTW, in regards to template constraints (not the rest), he does have a point. We have raised the exact same issues here on the boards more than once.
>
> The more I think of it, the more this whole duck typing for templates is probably a bad solution because we lack tool to express « meta types ».

I'm starting to think so too.

On Saturday, 9 March 2013 at 18:46:23 UTC, Peter Alexander wrote:
> [..]
> I suppose a better solution to this problem would involve someway of specifying that random access ranges are a subtype of input ranges, and the overload resolution would recognise that the random access range version is preferable to the more general version when available.

I wonder how would these "polymorphic concepts" work exactly. The following is pseudo-code:

concept A1 {
    void foo();
}

concept A2 : A1 { // A2 extends A1
    void bar();
}

concept B1 {
    void fun();
}

concept B2 : B1 {
    void gun();
}

struct S1 implements A2 {
    void foo() { }
    void bar() { }
}

struct S2 implements B2 {
    void fun() { }
    void gun() { }
}

void dostuff(A1, B1)(A1 a, B1 b) { } // Overload-1
void dostuff(A2, B1)(A2 a, B1 b) { } // Overload-2

void main() {
    S1 s1;
    S2 s2;
    dostuff(s1, s2); // calls the more specialized Overload-2
}

// But, if we add the following overload, then the above
// function call dostuff(s1, s2) doesn't know whether to
// call Overload-2 or, the equally specialized, Overload-3:

void dostuff(A1, B2)(A1 a, B2 b) { } // Overload-3

// And, if we add yet another, more specialized, overload,
// then the previous ambiguity goes away:

void dostuff(A2, B2)(A2 a, B2 b) { }

On Tuesday, 12 March 2013 at 01:00:58 UTC, Andrej Mitrovic wrote:
> On 3/12/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> There's clearly a fundamental misunderstanding
>
> Clearly 10 people in here haven't read his sentence properly where he
> said "in the static if **condition**", and not the static if *block*.

That maybe so, he clearly changed the subject. We did discovered a bug because of it.

On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
> On Saturday, 9 March 2013 at 16:42:56 UTC, deadalnix wrote:
>> On Saturday, 9 March 2013 at 15:22:55 UTC, monarch_dodra wrote:
>>> [..]
>>> BTW, in regards to template constraints (not the rest), he does have a point. We have raised the exact same issues here on the boards more than once.
>>
>> The more I think of it, the more this whole duck typing for templates is probably a bad solution because we lack tool to express « meta types ».
>
> I'm starting to think so too.
>
> On Saturday, 9 March 2013 at 18:46:23 UTC, Peter Alexander wrote:
>> [..]
>> I suppose a better solution to this problem would involve someway of specifying that random access ranges are a subtype of input ranges, and the overload resolution would recognise that the random access range version is preferable to the more general version when available.
>
> I wonder how would these "polymorphic concepts" work exactly. The following is pseudo-code:
>
> concept A1 {
>     void foo();
> }
>
> concept A2 : A1 { // A2 extends A1
>     void bar();
> }
>
> concept B1 {
>     void fun();
> }
>
> concept B2 : B1 {
>     void gun();
> }
>
> struct S1 implements A2 {
>     void foo() { }
>     void bar() { }
> }
>
> struct S2 implements B2 {
>     void fun() { }
>     void gun() { }
> }
>
> void dostuff(A1, B1)(A1 a, B1 b) { } // Overload-1
> void dostuff(A2, B1)(A2 a, B1 b) { } // Overload-2
>
> void main() {
>     S1 s1;
>     S2 s2;
>     dostuff(s1, s2); // calls the more specialized Overload-2
> }
>
> // But, if we add the following overload, then the above
> // function call dostuff(s1, s2) doesn't know whether to
> // call Overload-2 or, the equally specialized, Overload-3:
>
> void dostuff(A1, B2)(A1 a, B2 b) { } // Overload-3
>
> // And, if we add yet another, more specialized, overload,
> // then the previous ambiguity goes away:
>
> void dostuff(A2, B2)(A2 a, B2 b) { }

Yes, that is the idea. It seems really cool.