On Saturday, 25 July 2015 at 00:45:06 UTC, Walter Bright wrote:
> On 7/24/2015 3:12 PM, deadalnix wrote:
>> On Friday, 24 July 2015 at 19:10:33 UTC, Walter Bright wrote:
>>> If I have a call tree,
>>> and at the bottom I add a call to interface X, then I have to add a constraint
>>> that additionally specifies X on each function up the call tree to the root.
>>> That is antiethical to writing generic code, and will prove to be more of a
>>> nuisance than an asset.
>>>
>>> Exactly what sunk Exception Specifications.
>>
>> In many language you have an instaceof keyword or something similar. You'd get :
>>
>> if (foo instanceof X) {
>>    // You can use X insterface on foo.
>> }
>>
>> vs
>>
>> static if (foo instanceof X) {
>>    // You can use X insterface on foo.
>> }
>>
>> The whole runtime vs compile time is essentially an implementation detail. The
>> idea is the very same.
>>
>> The most intriguing part of this conversation is that the argument made about
>> unitests and complexity are the very same than for dynamic vs strong typing (and
>> there is hard data that strong typing is better).
>>
>> Yet, if someone would make the very same argument in the case of dynamic typing,
>> both Walter and Andrei would not give it a second though (and rightly so). Yet,
>> nowhere the reason why this differs in ay that make the cost/benefit ratio shift
>> is mentioned. It is simply asserted as such.
>
>
> I don't see how this addresses my point at all. This is very frustrating.

The same "problems" that you are claiming will happen with with the compile time interfaces are the exact same as the problems that happen with normal types systems.

With the normal type system, if somewhere down the call tree you need X you need to either update your interface, make a new one and add it to the whole call tree, or cast.

If somewhere down the call tree a template needs X, then with this compile time interface thing, you would need to either update your interface, make a new one and add it to the whole call tree, or do some kind of static cast.

ITS THE SAME.

Your arguments for why not to do it are even the same that people give for dynamic typing, and we know how well that works out.

Current template types work like duck typing, which works, but its error prone, and your argument of unittests is obviously bad in the context of duck typing. We want a real type system for our template types.

You may be thinking, but why would you want a type system for template types, why not just use the normal type system? Well because we want static dispatch, and compile time introspection and static if and all the other great things we have at compile time.

On Saturday, 25 July 2015 at 00:49:38 UTC, Walter Bright wrote:
> On 7/24/2015 2:27 PM, Tofu Ninja wrote:
> No it isn't. Google QueryInterface(). Nobody lists all the interfaces at the top level functions, which is that Rust traits and C++ concepts require.

The only time you don't use the right interface for your needs is if you plan on casting somewhere down the line. But certainly there are people who don't do that, I for one feel it's bad practice to need to use casts to circumvent the type system like that.

On Saturday, 25 July 2015 at 00:49:38 UTC, Walter Bright wrote:
> Sigh. Nothing I post here is understood.

Then make yourself more clear...

On Saturday, 25 July 2015 at 01:22:15 UTC, Tofu Ninja wrote:
> On Saturday, 25 July 2015 at 00:49:38 UTC, Walter Bright wrote:
>> On 7/24/2015 2:27 PM, Tofu Ninja wrote:
>> No it isn't. Google QueryInterface(). Nobody lists all the interfaces at the top level functions, which is that Rust traits and C++ concepts require.
>
> The only time you don't use the right interface for your needs is if you plan on casting somewhere down the line. But certainly there are people who don't do that, I for one feel it's bad practice to need to use casts to circumvent the type system like that.

I confess that I've always thought that QueryInterface was a _horrible_ idea, and that if you need to cast your type to something else like that, you're doing something wrong. *shudder* I really have nothing good to say about COM actually...

- Jonathan M Davis

On Saturday, 25 July 2015 at 01:15:52 UTC, Walter Bright wrote:
> On 7/24/2015 4:19 PM, Bruno Queiroga wrote:
>> Could not the compiler just issue a warning
>
> Please, no half features. Code should be correct or not.

Yeah. I wish that no one had ever managed to convince you to add -w and -wi to dmd. :)

-w is particularly bad, since it affects what code will and won't compile, which affects stuff like is expressions, so -w can actually affect the behavior of your program, even if it doesn't actually result in any errors being printed out. We really should just make it do the same thing as -wi IMHO.

In any case, I strongly concur with the idea that warnings are a bad idea. A good developer is going to fix all warnings, which ultimately makes them the same as errors anyway, and a bad developer will just leave them there and make them useless, because there will be too many of them to read.

- Jonathan M Davis

On Saturday, 25 July 2015 at 01:15:52 UTC, Walter Bright wrote:
> On 7/24/2015 4:19 PM, Bruno Queiroga wrote:
>> Could not the compiler just issue a warning
>
> Please, no half features. Code should be correct or not.
>
 ...
> ... (consider if bar was passed as an alias)


trait S1 { void m1(); }
trait S2 : S1 { void m2(); }

void bar(S : S2)(S s) {
    s.m1(); // ok...
    s.m2(); // ok...
}

template foo(S : S1) {
    static void foo(alias void f(S))(S s) {
        s.m1(); // ok...
        s.m2(); // ERROR: S1 is the base trait of S
        f(s);   // Ignored: typeof(s) is S of f(S)
    }
}

void main(string[] args) {
    S2 s2;

    alias foo!S2 fooS2;
    alias bar!S2 barS2;
	
    fooS2!barS2(s2);
}


??

On 7/24/2015 7:28 PM, Jonathan M Davis wrote:
> I confess that I've always thought that QueryInterface was a _horrible_ idea,

Specifying every interface that a type must support at the top of the hierarchy is worse. Once again, Exception Specifications.

I suspect that 3 or 4 years after concepts and traits go into wide use, there's going to be a quiet backlash against them. Where, once again, they'll be implementing D's semantics. Heck, C++17 could just as well be renamed C++D :-) given all the D senabtucs they're quietly adopting.

On Saturday, 25 July 2015 at 03:11:59 UTC, Walter Bright wrote:
> On 7/24/2015 7:28 PM, Jonathan M Davis wrote:
>> I confess that I've always thought that QueryInterface was a _horrible_ idea,
>
> Specifying every interface that a type must support at the top of the hierarchy is worse. Once again, Exception Specifications.


But that is what every one does.... you are really making me "wut" right now? I never use casts and every thing works out fine. And generally that is what is considered good oop practice. Its not like there is a list at the top of the tree of all the interfaces, there is just a type at the top of the tree that implements them all, its not like Exception Specifications.

On 7/24/2015 8:43 PM, Tofu Ninja wrote:
> there is just a type at the top of the tree that
> implements them all

The one type that encompasses everything defeats the whole point of type checking, traits, concepts, etc.

On 7/24/2015 11:50 AM, H. S. Teoh via Digitalmars-d wrote:
> The only way to achieve this is to explicitly
> negate every condition in all other overloads:

Another way is to list everything you accept in the constraint, and then separate out the various implementations in the template body using static if.

It's a lot easier making the documentation for that, too.