On Sunday, 20 October 2019 at 19:58:28 UTC, Max Samukha wrote:
> On Sunday, 20 October 2019 at 17:46:07 UTC, Meta wrote:
>
>>
>> I'm not saying that allowing to differentiate between implementations would be worthless, just that it's not a bug that D collapses them into 1 in the implementing class.
>
> I still do not follow why the diamond problem and the lack of data members is relevant. For me, it is not different from:
>
> struct A {
>     int x;
> }
>
> struct B {
>     int x;
> }
>
> Both types are isomorphic to int, but we still consider them distinct types and x's inside them unrelated, even though they are typed and named identically.

That's not really a correct analogy, because A and B are carrying mutable state. As I said, interfaces carry no state. Let's imagine that they could:

interface A { int n; void setN(int n); int getN(); }
interface B { int n; void setN(int n); int getN(); }

class C: A, B
{
    //Does super refer to A here, or B?
    override void setN(int n) { this.n = n; }
    override void getN() { return this.n; }
}

If this was possible in the language, it would become VERY important to be able to specify which interface you were implementing getN and setN for, because now this code would do something different depending on whether `this.n` refers to A's n member or B's:

void takesA(A a) { writeln("Got an A with n = ", a.getN()); }

void takesB(B b) { writeln("Got a B with n = ", b.getN()); }

C c = new C();
c.setN(10); //Is A.n set or B.n?

//What do these methods print? What should they?
takesA(c);
takesB(c);

This should hopefully make more clear why the fact that interfaces carry no mutable state means that it doesn't matter whether C.setN / C.getN refers to C.A.getN/setN or C.B.getN/setN.

Now, as has been pointed out, A's getN / setN methods may carry a different semantic meaning from B's (or, to go back to the original example, Display.fmt may _mean_ something very different from Debug.fmt). In that light, it would probably be useful to be able to tell the compiler that you want a different implementation for one interface method vs. the other, even though they have the exact same method signatures.

On Monday, 21 October 2019 at 13:20:05 UTC, Exil wrote:
> On Monday, 21 October 2019 at 12:34:14 UTC, Meta wrote:
>> On Sunday, 20 October 2019 at 20:41:01 UTC, Exil wrote:
>>> Sure, one can argue that it's not a bug, auto-decoding isn't a bug, in fact it was very much intentional. But I think we'd all be better off without it. The way it is implemented can lead to bugs quite easily. Since it picks whichever one based on order.
>>
>> Show me a concrete example. Also, there is no "picking" of which interface method is implemented. Both are implemented by the same method.
>
> interface OneThing {
>     void foo(); // should do One thing
> }
>
> interface AnotherThing {
>     void foo(); // do another thing
> }
>
> class A : OneThing, AnotherThing {
>     override void foo() { }
> }
>
>
> void bar(OneThing o) {
>    o.foo(); // do something unrelated to AnotherThing
> }
>
> void tar(AnotherThing a) {
>    a.foo(); // do something unrelated to OneThing
> }
>
>
> void main() {
>     A a = new A;
>
>     bar(a);
>     tar(a);
> }
>
>
> Your assumption is that just because the functions are named the same thing then they should do the exact same thing.

You're talking about the semantic appropriateness of A.foo doing the same thing whether A is accessed through a reference to a OneThing or an AnotherThing. I'm talking about whether it is a bug or not, i.e., the correctness of the behaviour of the implementation from a theoretical perspective.

Compiler's don't examine your code for conformance to a given set of semantics; that's up to humans. The best they can do is check that your program is well-formed.

On Monday, 21 October 2019 at 13:44:16 UTC, Meta wrote:
> You're talking about the semantic appropriateness of A.foo doing the same thing whether A is accessed through a reference to a OneThing or an AnotherThing. I'm talking about whether it is a bug or not, i.e., the correctness of the behaviour of the implementation from a theoretical perspective.

No I'm not. Whether "foo" should do the same thing or not is irrelevant. I'm not talking about the semantics of it. I've used libraries where the same method name does different things. Under the right circumstances this is going to be true. Programming languages is a subset of written/spoken language, and English is full of ambiguities. With words having multiple meanings depending on what context they are used in.

> Compiler's don't examine your code for conformance to a given set of semantics; that's up to humans. The best they can do is check that your program is well-formed.

I'm talking about what is available to the user should they encounter this problem. There's no workaround to the problem, not an easy or clean one like one that can be easily implemented. Your arguing that no changes need to be made because Java does it that way. I don't agree with that at all, especially since it is Java. If that were the criteria for "correctness" we would not have operator overloading.

On Monday, 21 October 2019 at 17:39:48 UTC, Exil wrote:
> On Monday, 21 October 2019 at 13:44:16 UTC, Meta wrote:
>> [...]
>
> No I'm not. Whether "foo" should do the same thing or not is irrelevant. I'm not talking about the semantics of it. I've used libraries where the same method name does different things. Under the right circumstances this is going to be true. Programming languages is a subset of written/spoken language, and English is full of ambiguities. With words having multiple meanings depending on what context they are used in.
>
> [...]


So what are some solutions to this? How do you call the semantically correct one from inside foo?

On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:

> I agree and support all of this. I know that dmd as a library right now can only be used from dub with `~master`. What is the technical reason stopping a version number again?

I'll like to add that I think this is the least of our problems with DMD as a library.

--
/Jacob Carlborg

On Monday, 21 October 2019 at 10:46:40 UTC, Alex wrote:
>
> This is interesting. Can you provide a source of why the nominal type system is a contradiction to the current approach?
> I mean, currently I can follow Meta more:
> If you have an object implementing both, Debug and Display, then the class has to implement foo. And if it does, it can be handled by functions both handling Debug and Display. The ambiguity is solved at this level:
>
> ´´´
> interface De{ void foo(); }
> interface Di { void foo(); }
> class C : De, Di{ override void foo(){} }
> void main()
> {
>     auto c = new C();
>     //c.fun1; //fails to compile, as you would expect
>     De de = c;
>     Di di = c;
>     de.fun1;
>     di.fun1;
> }
> auto fun1(De de){ de.foo; }
> auto fun1(Di di){ di.foo; }
> ´´´
>
> So, for sure, if you want to have different overloads for different interfaces, then, they can't go into the class of C. But there is no need to do so.

I don't understand why multiple inheritance is allowed except this lethal "diamond problem" has been implemented in a language which would seem to be a fair limitation. I have programmed C++ for decades and I have never used virtual inheritance when diamond like inheritance has happened, zero times. Also I have never encountered I had to rearrange the inheritance in order to avoid the diamond problem. However, I use multiple inheritance often in terms of that one class inherits from several other classes but the inheritance is fairly flat and the inherited classes never have any common parent class.

On Tuesday, 22 October 2019 at 14:37:25 UTC, IGotD- wrote:
>
> I don't understand why multiple inheritance is allowed except this lethal "diamond problem" has been implemented in a language which would seem to be a fair limitation. I have programmed C++ for decades and I have never used virtual inheritance when diamond like inheritance has happened, zero times. Also I have never encountered I had to rearrange the inheritance in order to avoid the diamond problem. However, I use multiple inheritance often in terms of that one class inherits from several other classes but the inheritance is fairly flat and the inherited classes never have any common parent class.

This one belongs to the section of "why is something done, in the way it is done". I'm the wrong addressee here.
I was asking, how the theory of the nominal type system is contradicting the existing solution.

On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
>On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
> This thread is for general feedback and discussion regarding Átila's blog post on his vision for D's future.
>
> https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/

Good write-up. Technical. Speaking about D "the language". But what about D "the project" ? They are not the same things. Things stay technical as long myself and 3-4 other persons are "the project" and focus on solving a technical problem. But, as soon as more people get involved it gets fast out of hand. Political and social skills have to be involved. Economics rears it's ugly head. $$$ are needed.

What is Attila's vision on "D, the project" ? What are his goals , what does he want to accomplish as a leader? Same goes for walter.

To be  frank, I posted some things here two years ago, then just lurked in read only mode by time in time, but to this day I have no freaking idea where Walter/Andrei/Attila/wheoever else wants to go with D project and what goals they have, and what is done to get there.  And this is bad. No clear road ahead, at least how I perceive it. It always gave me the impression that neither the project and the language founds it's identity.

On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
> This thread is for general feedback and discussion regarding Átila's blog post on his vision for D's future.
>
> https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/

I like most of the meta goals that are listed in the blog post.

However, I would like to see a road map with some specifics and time estimates attached to them.

I'm really interested in the "Make D the default implementation language" section.
And this comes from a semi failed experiment of mine trying to code a C library in D using -betterC. My conclusions:

- You miss the nice dynamic arrays and hash map structures, and others. You end-up rolling your own or wrapping C libraries, which requires lots of effort.
- There is no way to generate C/C++ header files from your extern(C/C++) declaration, I know this is being worked on. So had to roll my own.
- I had to roll out my own RefCount, Nullable and friends.
- At that time copy ctor was not available, so me wanting to properly use immutable for non POD types was a pain.
- CTFE is severely limited.
Most of these are tracked as bugs already, in case *thatsomeone* asks :)

All these problems are systemic and come from the lack of orthogonality in the core and std libs, the language had some improvements in using a template based run-time interface, but still has warts like no betterC CTFE. There are a lot of assumptions about what is available in terms of language and run-time, and vast majority of APIs in std lib is written with RTTI, exceptions and GC in mind.
In a perfect world core/std APIs will be layered bottom-up, so you have access to some (most?) algorithms and data structures from the lower denominator (betterC) till up the chain with GC, exceptions, type info where it makes sense.
It's the "pay as you go" mindset, that was discussed at length on this forum, that is not a reality yet.
std.v2 could be a good place to exercise this, as it could liberate the way APIs are constructed and how the whole thing plays together.

So there is a great deal of potential there for library writers, you can write some nice and elegant system code that can be used from any language, using the C API (or even C++), and still maintain the higher level D API, all without a fat run-time attached.

On Thursday, 24 October 2019 at 12:35:43 UTC, Radu wrote:
> snip

Fully agree, and it'd be nice to see a concerted effort as betterC is actually very nice, and I imagine in terms of user code there is a lot of work getting duplicated (rolling your own dynamic/assoc arrays etc).

The question is how would a transition look? I know it's a pretty insurmountable amount of work at this point but the improvement of betterC over C itself could justify it.