On 10/19/2019 8:45 PM, rikki cattermole wrote:
> Surely the lexer and its support infrastructure can be separated out into its own sub package?

Sorry, I'm worn out on that topic.

On 10/19/2019 4:38 PM, aliak wrote:
> Plus, IIRC dmd is a prime example where splitting is not happening because of "reasons".

dmd was originally developed as a C++ program, which did not have modules. Hence its organization is not the D module system best practices, and it isn't really fair to hold it as an example of D best practices.

I don't think Phobos is a great example of module best practices, either, but that is somewhat forgivable because Phobos was designed long before we knew what D best practices should be. (In particular, Phobos tends to lump too many unrelated things into each module.)

In D, declarations are grouped into a module that would otherwise need "friend" access if it were developed in C++.

On 20/10/2019 6:16 PM, Walter Bright wrote:
> On 10/19/2019 8:45 PM, rikki cattermole wrote:
>> Surely the lexer and its support infrastructure can be separated out into its own sub package?
> 
> Sorry, I'm worn out on that topic.

Fair enough, we can come back to it if we ever get close to getting a working IDE shell :)

On 10/16/2019 12:28 PM, H. S. Teoh wrote:
> Given how much time and effort has been poured
> into -betterC recently,

It wasn't that much. It was mainly turning some things off. I probably spent more time documenting it, writing an article, and doing a presentation on it than implementation.


> it begs the question, why?  What does the
> leadership think of the results of this survey?  Does it think it's time
> to reconsider the amount of effort put into -betterC?
Since -betterC is done, it's not like we can go back in time and take a different fork in the road. We cannot reconsider that effort.

28% of D users using it is quite a nice return on the little time invested in it. It also provides an effective answer to those who want to use D without GC and the runtime library, which was a constant issue.

I myself have found betterC very handy for writing tiny utilities that used to be in C. It's well suited for use in embedded systems.

On 10/17/2019 5:54 AM, Atila Neves wrote:
> String interpolation was very popular at that survey and that's happening.

That has multiple DIPs for it. So does named arguments. I've written DIPs for both. I've also done a DIP for @safe as default.

On Sun, 2019-10-20 at 03:23 +0000, John Belmonte via Digitalmars-d wrote:
> 
[…]
> Rust appears to be going down the wrong concurrency path.
[…]

I believe you need to expand on this claim. As far as I am aware there are a number of structured concurrency crates, e.g. Rayon.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Sunday, 20 October 2019 at 05:43:52 UTC, Walter Bright wrote:
> On 10/19/2019 4:38 PM, aliak wrote:
>> Plus, IIRC dmd is a prime example where splitting is not happening because of "reasons".
>
> dmd was originally developed as a C++ program, which did not have modules. Hence its organization is not the D module system best practices, and it isn't really fair to hold it as an example of D best practices.

Oh I know, it was a reply to Nicholas proposing splitting up a module as a general solution to something - but that's not always possible.

>
> I don't think Phobos is a great example of module best practices, either, but that is somewhat forgivable because Phobos was designed long before we knew what D best practices should be. (In particular, Phobos tends to lump too many unrelated things into each module.)
>
> In D, declarations are grouped into a module that would otherwise need "friend" access if it were developed in C++.

Yeah this was related to benefits around being able to keep some things private from your friends (which is not d-able currently).

On Sunday, 20 October 2019 at 08:44:37 UTC, aliak wrote:
> On Sunday, 20 October 2019 at 05:43:52 UTC, Walter Bright wrote:

>>
>> In D, declarations are grouped into a module that would otherwise need "friend" access if it were developed in C++.
>
> Yeah this was related to benefits around being able to keep some things private from your friends (which is not d-able currently).

===
module mypack.publicstuff.stuff.secretstuff;

class SecretStuff {
   public foo {}
   package friendlyFoo {]
   private secretFoo {]
}

===
module mypack.publicstuff.stuff.friends;

void beFriendly(SecretStuff s) {
   s.friendlyFoo();
}
...
===
module mypack.publicstuff;

public import mypack.publicstuff.stuff.friends,
              mypack.publicstuff.stuff.secretstuff;

...
===

On Saturday, 19 October 2019 at 23:09:11 UTC, Meta wrote:
> void main()
> {
>     Display dsp = new Test();
>     Debug dbg = new Test();
>     dsp.fmt();
>     dbg.fmt();
> }

You can't do that if the interfaces come from third parties. There is a half-working hack using nested classes, but it is obviously inadequate:

interface A {
    void foo();
}

interface B {
    void foo();
}

class C: A {
    private final class _B: B {
        override void foo() {
            this.outer.bFoo();
        }
    }

    private _B _b;
    final B b() {
        return _b;
    }
    alias b this;

    this() {
        _b = new _B();
    }

    import std.stdio;
    override void foo() {
        writeln("A.foo");
    }

    void bFoo() {
        writeln("B.foo");
    }
}


class D: C {
}

void main() {
    auto c = new C;
    // auto c = new D; // won't work because of broken 'alias this'
    A a = c;
    B b = c;

    a.foo(); // "A.foo"
    b.foo(); // "B.foo"
}

On Saturday, 19 October 2019 at 22:14:55 UTC, Meta wrote:

>
> It's not a defect. Interfaces have no state, so it doesn't matter which is called. Java does the same thing.

What do you mean by 'have no state'? If Java does the same thing, it does it wrong. Nominal typing is all about avoiding structural conflicts. Members coming from different nominal types should not be conflated.