On 7/24/15 11:12 PM, 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.

That would be an oversimplification.

> Once again, Exception Specifications.

And that simile would be superficial.


Andrei

On 7/25/15 5:34 AM, Walter Bright wrote:
> On 7/25/2015 2:14 AM, Jonathan M Davis wrote:
>> I do think that it can make sense to put very similar overloads in a
>> single
>> function with static if branches like you're suggesting, but I do
>> think that
>> it's a bit of a maintenance issue to do it for completely distinct
>> overloads -
>> especially if there are several of them rather than just a couple. But
>> it's
>> still possible to combine their template constraints at a higher level
>> and have
>> overloaded functions rather than simply using static ifs.
>
> I also sometimes see:
>
>     void foo(T)(T t) if (A && B) { ... }
>     void foo(T)(T t) if (A && !B) { ... }
>
> The user should never have to see the B constraint in the documentation.
> This should be handled internally with static if.

There are problems with that but I do agree with the sentiment. -- Andrei

On 7/25/15 6:05 AM, 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.

I disagree. -- Andrei

On Saturday, 25 July 2015 at 12:09:34 UTC, Andrei Alexandrescu wrote:
>> However, making
>> it built-in feels really convenient in Rust:
>>
>> - considerably less function declaration visual noise
>> - much better error messages: trying to use methods of T not defined by
>> a trait will result in compile-time error even without instantiating the
>> template
>
> Yah, building stuff in does have its advantages.

I feel it is not as much about "built-in vs library", but "generic vs templates" - somewhat deeper ideological difference that consequently calls for different tools. Metaprogramming with traits in Rust is inconvenient to the point of being almost impossible but generics have a very strong static API verification. In D you can get destroyed by flow of deeply nested error messages but the magic you can do with templates with minimal effort investment is beyond comparison.

Different values, different trade-offs.

On 7/25/15 9:17 AM, Brendan Zabarauskas wrote:
> 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.
>>
>>
>>
>> BTW, you might want to remove the UTF-8 characters from your user
>> name. Evidently, NNTP doesn't do well with them.
>
> I think the point is that trait based constraints force compilation
> errors to be raised at the call site, and not potentially from deep
> within a template expansion. Template errors are stack traces coming
> from duck typed, compile time programs. Library authors can't rely on
> the typechecker to pick up on mistakes that may only appear at expansion
> time in client programs.

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

On 25 July 2015 at 18:48, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 7/24/2015 11:10 PM, Jonathan M Davis wrote:
>>
>> So, maybe we should look at something along those lines rather than proliferating the top-level function overloading like we're doing now.
>
>
> Consider the following pattern, which I see often in Phobos:
>
>     void foo(T)(T t) if (A) { ... }
>     void foo(T)(T t) if (!A && B) { ... }
>
> from a documentation (i.e. user) perspective. Now consider:
>
>     void foo(T)(T t) if (A || B)
>     {
>          static if (A) { ... }
>          else static if (B) { ... }
>          else static assert(0);
>     }
>
> Makes a lot more sense to the user, who just sees one function that needs A or B, and doesn't see the internal logic.

This! I've felt this way with phobos in particular for ages.
I've argued this exact case before, and it's been rejected.
I much prefer static if inside functions rather than pollute the
namespace (and docs) with a bunch of overloads. Also, these symbols
with lots of constraints can get really long!

On 7/25/15 9:35 AM, Dicebot wrote:
> This is absolutely impractical. I will never even consider such attitude
> as a solution for production projects. If test coverage can't be
> verified automatically, it is garbage, period. No one will ever manually
> verify thousands lines of code after some trivial refactoring just to
> make sure compiler does its job.

Test coverage shouldn't totter up and down as application code is written - it should be established by the unittests. And yes one does need to examine coverage output while writing unittests.

I do agree more automation is better here (as is always). For example, if a template is followed by one or more unittests, the compiler might issue an error if the unittests don't cover the template.


Andrei

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.

Well, I am not sure if the flexibility scales up when clever library authors start to write flexible introspective code. It basically requires library authors to be careful and conservative.

Code coverage and unit tests cannot replace a robust type system when you get down to composable datastructures due to the combinatorial explosion you get.

> The idea that Rust traits check at compile time and D does not is a total misunderstanding.

I'm not arguing in favour of copying Rust… I don't think becoming more like Rust will buy D more friends. It will just be an argument for picking Rust over D.

If I'd argue for something it would be for having a real deductive database at the heart of the templating type system.

> BTW, you might want to remove the UTF-8 characters from your user name. Evidently, NNTP doesn't do well with them.

Hm. It works in the web interface when I reply to my own messages, maybe just a client issue?

On 07/25/2015 05:03 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com> wrote:
> On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote:
>> BTW, you might want to remove the UTF-8 characters from your user name. Evidently, NNTP doesn't do well with them.
> 
> Hm. It works in the web interface when I reply to my own messages, maybe just a client issue?
> 
    I'd say it is a problem with the way the web interface encodes the
sender name, and especially the fact that it starts with a double quote.
In the message source, it looks like:

From: "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
 <ola.fosheim.grostad+dlang@gmail.com>

    According to RFC 2047 [1]: "An 'encoded-word' MUST NOT appear within
a 'quoted-string'." (top of page 7), so this should be written as:

From: Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=
 <ola.fosheim.grostad+dlang@gmail.com>

        Jerome

[1] https://tools.ietf.org/html/rfc2047
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On Saturday, 25 July 2015 at 14:28:31 UTC, Andrei Alexandrescu wrote:
> On 7/25/15 9:35 AM, Dicebot wrote:
>> This is absolutely impractical. I will never even consider such attitude
>> as a solution for production projects. If test coverage can't be
>> verified automatically, it is garbage, period. No one will ever manually
>> verify thousands lines of code after some trivial refactoring just to
>> make sure compiler does its job.
>
> Test coverage shouldn't totter up and down as application code is written - it should be established by the unittests. And yes one does need to examine coverage output while writing unittests.

Does word "refactoring" or "adding new features" ring a bell? In the first case no one manually checks coverage of all affected code because simply too much code is affected. Yet it can become reduced by an accident. In the second case developer is likely to check coverage for actual functionality he has written - and yet coverage can become reduced in different (but related) parts of code because that is how templates work.

You will have a very hard time selling this approach. If official position of language authors is that one must manually check test coverage all the time over and over again, pragmatical people will look into other languages.

> I do agree more automation is better here (as is always). For example, if a template is followed by one or more unittests, the compiler might issue an error if the unittests don't cover the template.

This isn't "better". This is bare minimum for me to call that functionality effectively testable. Manual approach to testing doesn't work, I thought everyone has figured that out by 2015. It works better than no tests at all, sure, but this is not considered enough anymore.