On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote:
> On 7/25/2015 12:19 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com> wrote:
>> The point of having a type system is to catch as many mistakes at compile time
>> as possible. The primary purpose of a type system is to reduce flexibility.
>
> Again, the D constraint system *is* a compile time system, and if the template body uses an interface not present in the type and not checked for in the constraint, you will *still* get a compile time error.
>
> The idea that Rust traits check at compile time and D does not is a total misunderstanding.
>

Obvious, everything is at compile time here. Still, there is 2 steps, compiling the template (equivalent to compile time in the dynamic dispatch case), and instantiating the template (equivalent to runtime in the dynamic dispatch case).

That is the exact same problem.

On Saturday, 25 July 2015 at 10:01:43 UTC, Walter Bright wrote:
> On 7/24/2015 10:59 PM, Jonathan M Davis wrote:
>> In any case, looking at this, I have to agree with you that this is the same
>> problem you get with checked exceptions / exceptions specifications - only worse
>> really, because you can't do "throws Exception" and be done with it like you can
>> in Java (as hideous as that is). Rather, you're forced to do the equivalent of
>> listing all of the exception types being thrown and maintain that list as the
>> code changes - i.e. you have to make the top-level template constraint list all
>> of the sub-constraints and keep that list up-to-date as the sub-constraints
>> change, which is a mess, especially with deep call stacks of templated functions.
>
> Phew, finally, someone understands what I'm talking about! I'm really bad at explaining things to people that they aren't already familiar with.
>
> I'm not sure, but I suspect this problem may cripple writing generic library functions that do one operation and then forward to the next (unknown in advance) operation in a chain.
>
> It also may completely torpedo Andrei's Design By Introspection technique.

This only make sense under the premise that both technique are mutually exclusive, which they aren't, and that no introspection can be done, which nobody argues against (I'm not sure what Rust provide here, but if they don't allow it, they'll regret it).

On Saturday, 25 July 2015 at 10:05:35 UTC, Tofu Ninja wrote:
> On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote:
>> if the template body uses an interface not present in the type and not checked for in the constraint, you will *still* get a compile time error.
>
> But only if the template gets instantiated with a bad type. Unit tests don't catch every thing and have to be written properly. A proper type system should catch it.

This unitest argument is becoming ridiculous. Unless some strong argument is brought to the table that this differs from the "dynamic typing is not a problem if you write unitest" we we all should know is bogus at this point, it can't be taken seriously.

On Saturday, 25 July 2015 at 12:05:12 UTC, Andrei Alexandrescu wrote:
> Well at least all paths must be compiled. You wouldn't ship templates that were never instantiated just as much as you wouldn't ship any code without compiling it. We've had a few cases in Phobos a while ago of templates that were never instantiated, with simple compilation errors when people tried to use them. -- Andrei

That is an instance of happy case testing. You test that what you expect to work work. You can't test that everything that is not supposed to work do not, or that you don't rely on a specific behavior of the thing you are testing.

On Saturday, 25 July 2015 at 12:15:04 UTC, Andrei Alexandrescu wrote:
> On 7/23/15 4:52 PM, Walter Bright wrote:
>> On 7/23/2015 1:08 PM, Dicebot wrote:
>>  > I am not sure how it applies.
>>
>> D interfaces (defined with the 'interface' keyword) are simple dispatch
>> types, they don't require an Object. Such interfaces can also have
>> default implementations.
>
> Is this new? I agree we should allow it, but I don't think it was added to the language yet.
>
> Andrei

This is not in the language and should not be added lightly. There is all kind of collisions that could happen, and they need proper disambiguate rules.

Scala trait (different beast from Rust traits) is a successful implementation of this.

On Saturday, 25 July 2015 at 12:53:37 UTC, Andrei Alexandrescu wrote:
> FWIW I think traits are better than concepts. -- Andrei

Can you explain this in more details ?

On Saturday, 25 July 2015 at 13:37:15 UTC, Andrei Alexandrescu wrote:
> On 7/24/15 6:12 PM, deadalnix wrote:
>> 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).
>
> No, that's not the case at all. There is a distinction: in dynamic typing the error is deferred to run time, in this discussion the error is only deferred to instantiation time. -- Andrei

In case 1, it is argued that unitest check runtime, so we are good, and in case 2, unitest check instantiation, so we are good.

That is the very same argument and it is equally bogus in both cases.

On Saturday, 25 July 2015 at 13:47:05 UTC, Andrei Alexandrescu wrote:
> On 7/24/15 9:16 PM, Tofu Ninja wrote:
>> 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.
>
> Could you please make the obvious explicit?
>
>> We want a real type system for our template types.
>
> Every time this (or really any apology of C++ concepts) comes up, the discussion has a similar shape:
>
> 1. Concepts are great because they're a type system for the type system! And better error messages! And look at these five-liners! And Look at iterators! And other nice words!
>
> 2. I destroy them.
>

So far, you've just rehashed bogous claim made for dynamic typing decades ago and proven wrong decades ago.

> 3. But we want concepts because they're a type system for the type system! And ... etc. etc.
>
> I have no idea how people can simply ignore the fact that their arguments have been systematically dismantled.
>
>
> Andrei

Because you only think you did, but really didn't.

On Saturday, 25 July 2015 at 13:59:11 UTC, Andrei Alexandrescu wrote:
> Understood, but by the same token library authors shouldn't ship untested code. This is basic software engineering. Once we agree on that, we figure that concepts help nobody. -- Andrei

Understood, but by the same token library authors shouldn't ship untested code. This is basic software engineering. Once we agree on that, we figure that [type system|grizzly|unicorns] help nobody.

That is a statement, not an argument.

On Saturday, 25 July 2015 at 20:48:06 UTC, Walter Bright wrote:
> On 7/25/2015 11:40 AM, Tobias Müller wrote:
>> I'm not convinced at all that checked exceptions (as implemented in Java,
>> not C++) don't work.
>>
>> My suspicion is that the usual Java code monkey is just too sloppy to care
>> and thus sees it more as a nuisance rather than the help that it is.
>
> Unfortunately, Bruce Eckel's seminal article on it http://www.mindview.net/Etc/Discussions/CheckedExceptions has disappeared. Eckel is not a Java code monkey, he wrote the book Thinking In Java
> http://www.amazon.com/gp/product/0131002872/

Yes, checked exception is bankrupt at this point. It was not clear at the time, now it is.