On Saturday, 19 October 2019 at 17:22:10 UTC, welkam wrote:
> On Saturday, 19 October 2019 at 11:21:10 UTC, Chris wrote:
>> [...]
>
>> [...]
> Talking != working. If people stopped talking that doesnt mean they would start working. Thats a huge mistake to make for some one who thinks he is the only reasonable person here.
>
> [...]

DeepGlance wrote code for a world leader company in Display Projections and Visualization Technologies to be run on ARM in a monitor, and we happily did it in D

On Saturday, 19 October 2019 at 13:04:26 UTC, John Belmonte 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.
>
>> Safe and easy concurrency
>
> I'd like to make another plea to get on board with structured concurrency.  That includes having a standard cancellation mechanism.

https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

Oh that is actually pretty nice. The nursery idea reminds me a bit of the coroutineScope in Kotlin. Makes a lot of sense.

On Saturday, 19 October 2019 at 15:55:38 UTC, Max Samukha wrote:
> On Friday, 18 October 2019 at 16:10:31 UTC, Atila Neves wrote:
>
>>
>> I don't understand what you mean by this. What is it about OOP in D now that you can't get done without a library solution? And why are library solutions insufficient for those purposes?
>
> One cringeworthy problem with D's implementation of interfaces and classes is how D resolves method conflicts. Conflicting interface methods are silently collapsed into one implementation, which seems to be by design and is definitely incorrect.
>
> interface Display {
>   void fmt();
> }
>
> interface Debug {
>   void fmt();
> }
>
> class C: Display, Debug {
>   override fmt() {  } // implements both interfaces
> }
>
> At the very least, this should be an ambiguity error. Some languages (C#, Rust) allow to disambiguate.

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

On Saturday, 19 October 2019 at 22:14:55 UTC, Meta wrote:
> On Saturday, 19 October 2019 at 15:55:38 UTC, Max Samukha wrote:
>> On Friday, 18 October 2019 at 16:10:31 UTC, Atila Neves wrote:
>>
>>>
>>> I don't understand what you mean by this. What is it about OOP in D now that you can't get done without a library solution? And why are library solutions insufficient for those purposes?
>>
>> One cringeworthy problem with D's implementation of interfaces and classes is how D resolves method conflicts. Conflicting interface methods are silently collapsed into one implementation, which seems to be by design and is definitely incorrect.
>>
>> interface Display {
>>   void fmt();
>> }
>>
>> interface Debug {
>>   void fmt();
>> }
>>
>> class C: Display, Debug {
>>   override fmt() {  } // implements both interfaces
>> }
>>
>> At the very least, this should be an ambiguity error. Some languages (C#, Rust) allow to disambiguate.
>
> It's not a defect. Interfaces have no state, so it doesn't matter which is called. Java does the same thing.

To work around this, you can use the "non-virtual interface" pattern (there are probably other ways; this is just what comes to mind):

import std.stdio;

interface Display
{
    protected void displayFmt();
    final void fmt() { displayFmt(); }
}

interface Debug
{
    protected void debugFmt();
    final void fmt() { debugFmt(); }
}

class Test: Display, Debug
{
    override void displayFmt() { writeln("inside Display.fmt"); }
    override void debugFmt() { writeln("inside Debug.fmt"); }
}

void main()
{
    Display dsp = new Test();
    Debug dbg = new Test();
    dsp.fmt();
    dbg.fmt();
}

On Saturday, 19 October 2019 at 17:27:26 UTC, Nicholas Wilson wrote:
> On Saturday, 19 October 2019 at 13:45:37 UTC, Aliak wrote:
>> On Saturday, 19 October 2019 at 12:23:36 UTC, Nicholas Wilson wrote:
>>> IME, no. If your module is big enough that you can't keep all of it in you head and you start calling implementation details of your classes _by accident_ then either:
>>> a) name your implementation details so they stand out so you don't call by accident (e.g. a._something() )
>>> b) split up your module into a package so that it fits in your head, this will (probably) cause you to not be able to call the implementation details at all, and will thus cause you to have to think about the organisation of you package (which is probably a good thing).
>>
>> Solution a is a convention.
>
> Indeed.
>
>> And solution b is fluffy.
>
> How so? Also, you should probably be doing that anyway for different reasons.

As in "fits in your head" is not concrete. And it's usually not just "you" in a team. Plus, IIRC dmd is a prime example where splitting is not happening because of "reasons". So it's not always doable either.

Furthermore, neither solution allows you to completely encapsulate some vars in a type while allowing module functions to access others that are not accessible outside the module.

>
> Since I don't expect to convince you of anything further, the only thing I can suggest is to write a lint rule using the compiler as a library (or hack the compiler yourself), since changing the behaviour would almost certainly be rejected on cost (i.e. breaking stuff) / benefit, and adding a second private would probably also be rejected as too narrow a feature for marginal, at best, utility.
>
> I can't remember if you do compiler stuff, but I'd be happy to help once I have some time (or try slack for faster response from others).

Well, the problem is that I've used languages with moduleprivate and privateprivate and it's from experience that it's cleaner. So unless there're some actual disadvantages to having that extra granularity that I'm not seeing, I suppose there can't be any convincing (and really, I was just trying to point out that the notion that D's access levels are obviously the correct ones is arguable, therefore not obviously correct - re Mike's post)

And thank you :) appreciate the offer! But it's not something I care too much about. And to get something like this in I'd have to argue for why encapsulation of user defined types is a good thing. A if I actually have to argue for that, pretty sure it won't go anywhere. So it's just a level of access I accept is missing from D - one good thing about it is that it gives you less choice so you don't need to worry about privateprivate vs moduleprivate.

But anyway, curious, why do you think it's of marginal utility at best? And on a related note have you used any languages that provide both levels of granularity that I mention above?

On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:
> Furthermore, neither solution allows you to completely encapsulate some vars in a type while allowing module functions to access others that are not accessible outside the module.

You could still use interfaces for a total separation, even inside a module (well, unless a cast is used, but meh). Or opaque structs.

Someone on Stack Overflow this week asked me if we can do Javascript style fake modules in D, where the "private" members are local inside the function and the "public" ones are returned in the object... and indeed we can, which is another amusing way of achieving it, but even I think that is a bit too silly in D.


I personally wouldn't vote against adding like private(class) - such could be done without massive breakage - but I'm totally meh on the whole debate.

On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:
> On Saturday, 19 October 2019 at 17:27:26 UTC, Nicholas Wilson
>> How so? Also, you should probably be doing that anyway for different reasons.
>
> As in "fits in your head" is not concrete. And it's usually not just "you" in a team.

What I'm saying is a boundary point exists, even if is not precisely defined, passed which point separating your module into a package is a win for readability and reasonability.

> Plus, IIRC dmd is a prime example where splitting is not happening because of "reasons". So it's not always doable either.

Those reasons are largely "Walter" and are unrelated.

> And thank you :) appreciate the offer! But it's not something I care too much about. And to get something like this in I'd have to argue for why encapsulation of user defined types is a good thing. A if I actually have to argue for that, pretty sure it won't go anywhere. So it's just a level of access I accept is missing from D - one good thing about it is that it gives you less choice so you don't need to worry about privateprivate vs moduleprivate.

Indeed, no need for "friend".

> But anyway, curious, why do you think it's of marginal utility at best? And on a related note have you used any languages that provide both levels of granularity that I mention above?

Because that doesn't allow you to do anything fundamentally new, as in the above solutions _work_, even if they don't work as well as you'd like them to, and to me it serves as a marker that if you are running into that problem then you module is too large anyway you likely have other issues regarding trying to reason about the code.

No I haven't used both at the same time, but I've used them separately and I find that module private provides enough encapsulation that I don't find myself wanting something more (As opposed to C++ where this impossible because there is only textual inclusion, not symbolic imports).

On Saturday, 19 October 2019 at 20:22:21 UTC, Sebastiaan Koppe wrote:
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
>
> Oh that is actually pretty nice. The nursery idea reminds me a bit of the coroutineScope in Kotlin. Makes a lot of sense.

Kotlin has a good structured concurrency implementation.  Scopes can be configured to use either a single OS thread (for UI, or simply to make concurrency easier to reason about and avoid the need for explicit locking and an entire class of race conditions), or multiple OS threads with various mapping strategies.  It's also a good example of what minimum support is needed from the language, vs. what can exist in the coroutine library.

Interestingly, the team working on Kotlin's experimental coroutine library stumbled on structured concurrency independently.  Martin Sústrik's defined it first (and made the libdill C implementation), which Nathaniel Smith greatly expanded on with his article and Python library.  A great characteristic of these people is that they want to work together to improve the state of the art, and aren't competitive with respect to their implementations (https://trio.discourse.group/t/structured-concurrency-kickoff/).

Rust appears to be going down the wrong concurrency path.  Meanwhile C++ structured concurrency experiments have started (https://github.com/lewissbaker/cppcoro/, https://www.youtube.com/watch?v=1Wy5sq3s2rg).  It's either an opportunity for D, or a chance to fall behind...

The "founders" are very open to reviewing and consulting on getting structured concurrency right in other languages.  It would just take some mutual openness by D's stewards to have an honest look at where D is at and how it can move forward.

On 10/19/2019 6:52 PM, Nicholas Wilson wrote:
> On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:
>> Plus, IIRC dmd is a prime example where splitting is not happening because of "reasons". So it's not always doable either.
> Those reasons are largely "Walter" and are unrelated.

I know I'm not popular with this idea, but packagizing dmd is akin to painting a rusty/dirty car without prepping the metal first.

What I've been doing recently is a series of PRs aimed at OutBuffer, Array, and StringExp to:

1. use [] instead of * so that array bounds checking can be performed
2. use [] to reduce dependency on terminating 0s
3. make the data allocation private
4. prevent direct access to internal memory management
5. add debug code to ensure no dangling pointers

Fortunately, I found only a couple small issues with memory bugs.

While I'm still not proud of the abstractions, the amount of cowboy programming around them is significantly reduced, along with the possibility of bugs.

On 20/10/2019 4:41 PM, Walter Bright wrote:
> On 10/19/2019 6:52 PM, Nicholas Wilson wrote:
>> On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:
>>> Plus, IIRC dmd is a prime example where splitting is not happening because of "reasons". So it's not always doable either.
>> Those reasons are largely "Walter" and are unrelated.
> 
> I know I'm not popular with this idea, but packagizing dmd is akin to painting a rusty/dirty car without prepping the metal first.

It is on my list of things that need to happen for dmd-fe as a library to be "usable".

Surely the lexer and its support infrastructure can be separated out into its own sub package?

> What I've been doing recently is a series of PRs aimed at OutBuffer, Array, and StringExp to:
> 
> 1. use [] instead of * so that array bounds checking can be performed
> 2. use [] to reduce dependency on terminating 0s
> 3. make the data allocation private
> 4. prevent direct access to internal memory management
> 5. add debug code to ensure no dangling pointers

I saw that, tis' good work that!