On Saturday, 19 October 2019 at 11:46:21 UTC, drug wrote:
> I agree that in D having private to be in fact moduleprivate is unusual comparing to C++ for example.

In C++ you have no modules (modulo recent activity) and so the class is the only unit of encapsulation that there is apart from namespaces. In Java there you can only have a single class per module so module private and class private are the same thing (possibly modulo inner classes? idk I don't Java).

In D you can't not use modules _and_ you can have multiple declarations per module _and_ there is only one private (and no friend, or alternately everything in the modules are friends) so the line has to be drawn somewhere.

> But is it really bad in practice?

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).

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://forum.dlang.org/thread/ndirsnblaktyfellckil@forum.dlang.org

Futures -> bad.  Quoting Nathaniel Smith:

> Language design happens by stepwise incremental improvements. And like any form of gradient descent, it can get stuck in sub-optimal local minima. Futures are a really attractive local minima that have trapped C#, JS, Python, now Rust...

https://trio.discourse.group/t/structured-concurrency-in-rust/73/14

On Saturday, 19 October 2019 at 12:23:36 UTC, Nicholas Wilson wrote:
> On Saturday, 19 October 2019 at 11:46:21 UTC, drug wrote:
>> I agree that in D having private to be in fact moduleprivate is unusual comparing to C++ for example.
>
> In C++ you have no modules (modulo recent activity) and so the class is the only unit of encapsulation that there is apart from namespaces. In Java there you can only have a single class per module so module private and class private are the same thing (possibly modulo inner classes? idk I don't Java).
>
> In D you can't not use modules _and_ you can have multiple declarations per module _and_ there is only one private (and no friend, or alternately everything in the modules are friends) so the line has to be drawn somewhere.
>
>> But is it really bad in practice?
>
> 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. And solution b is fluffy. Neither are enforceable. But they are indeed things you can do to try and mitigate things. And it becomes exponentially harder to enforce conventional practices the bigger the code base. Unfortunately that’s only something you get to realize after enough experience in big code bases and in larger teams.

On Friday, 18 October 2019 at 17:23:17 UTC, H. S. Teoh wrote:
> On Fri, Oct 18, 2019 at 04:48:24PM +0000, Laurent Tréguier via Digitalmars-d wrote: [...]
>> Isn't it because 2.088.1 isn't semver-compliant ? It would need to be tagged at something like 2.88.1 (and thus changing the versioning scheme) to be recognized as a correct version by Dub, if I'm not mistaken
>
> This is a side-note, but I find it really ironic that semver started out as being a general principle of bumping version numbers semantically rather than arbitrarily, which isn't tied to any specific version syntax, but nowadays it seems to be become a stick with which to beat others over for not complying with a specific syntactic implementation of it.
>
>
> T

DMD would not be semver compliant even if it dropped the extra 0. As such, it's probably good that it has it in there, so people don't think it's semver just because it has a version number with three numbers.

DMD breaks compatibility in minor changes. It's not semver, it's more like dmd2-19.04.

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.

On Sat, Oct 19, 2019 at 03:55:38PM +0000, Max Samukha via Digitalmars-d wrote: [...]
> 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.

IMO, you should file a bug for this one.


T

-- 
"If you're arguing, you're losing." -- Mike Thomas

On Saturday, 19 October 2019 at 11:21:10 UTC, Chris wrote:
> On Saturday, 19 October 2019 at 10:37:12 UTC, drug wrote:
>
>>
>> I'm sincerely wondered why you can't stop posting here if you gave up using D long time ago? What is the reason that forces you to continue this non-technical correspondence?
>
> I'm sincerely wondering why the D community avoids doing the obvious and keeps wondering why adoption rates are still low, after 20 years. As I remember it was all about 1. ranges, 2. templates, 3. functional programming and 4. memory safety, nice, but basics were / and are still being neglected. I understand that many users might not care because e.g. they don't use IDEs or don't develop for mobile, but when people keep raising these issues and other new languages immediately work on ARM and IDE plugins, still nobody here sees the big pink elephant in the room. And it's not "scarce" resources, it's that nobody seems to care. If you think about the amount of time people spend discussing a syntactic detail in template declarations and stuff like that, and then people tell me there aren't enough resources, c'mon. The truth is that the community enjoys bikeshedding but ignores the basics. Maybe my conversation is non-technical in the sense that I don't bikeshed about template syntax, but stability, automagicaltooling and support for mobile are still technical issues. If you don't sort those out, D will remain a niche language. It's a nobrainer, really, I don't understand this obstinate resistance to the obvious.

> If you think about the amount of time people spend discussing a syntactic detail in template declarations and stuff like that, and then people tell me there aren't enough resources, c'mon.
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.

> when people keep raising these issues and other new languages immediately work on ARM and IDE plugins, still nobody here sees the big pink elephant in the room

Zig - doesnt have proper ARM support
Nim - it got it for free because it translates to C
Crystal - didnt had windows support not to mention arm
Rust - It kind of compiles but no tests are run so its not guaranteed to work. RustC and cargo are not supported on ARM.
Go - doesnt work on Android but has linux Arm support.
jai - ???

Before claiming of how other languages immediately work on on ARM do some fact checking. Yes Android is big but the only new language that has good support for it is Kotlin.

Here are some facts:
1. One of the first D language foundation expenditures were paying for Visual studio plugin enhancement. If you didnt know Visualstudio is an IDE and it was concluded that enhancing user experience was a key thing in making D grow. This directly contradicts your view.
2. Every year D foundation gets more money to invest in D. This and Ethans money kick started ARM effort. Money is still being raised for iOS port by the way. If as you say thing were not done because we didnt understood that things were important then tell me why we are still raising money? Why money was required to kickstart it in the first place?

While mobile development is huge its not the best strategic decision to invest huge amounts of resources pursuing that market. Let me explain. Firstly it is easier to sell water to a thirsty man. There is no indication that mobile people are thirsty for a new programming language. Second thing is that you would have to compete with Google and Apple at the same time. Competing against one is suicide let alone against both. If we did as you want D would fail because it would never reach the polish that Google or Apple can afford and with nothing to offer in other areas D would just die.

But there are other areas where people are thirsty for new programming language. They are:
1. Research
2. Game dev
3. Desktop application creation.

Researchers and scientist each day are facing with ever increasing data sets and python or R are chocking on those huge data sets. The other option researchers have is either C or C++ and they dont like programming in them. D as better C allows for easy library development which could be easily be used in Python or other languages that researches use. DasBetterC allowed development for mir glass library that is a cornerstone library for any subsequent development in research area. Little investment in this are is paying of big time with companies sponsoring development for new libraries and tools in D. With data frames support coming D is growing stronger in this are. Since "critics" never mention this area as growth opportunity show how much they really understand.

For game developers its very important to have C++ interoperability because there are lots of code already written in C++ and you cant just rewrite it. And what do you know there is effort in improving interoperability with C++.

On discord there is working group for GUI library.

It seems that people working on D perform const benefit analysis before investing and from what I can tell they are way better at deciding on what to work or where to best invest money than you.

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.

> Neither are enforceable. But they are indeed things you can do to try and mitigate things. And it becomes exponentially harder to enforce conventional practices the bigger the code base. Unfortunately that’s only something you get to realize after enough experience in big code bases and in larger teams.

Maybe, but this is a O(individual file size) problem not a O(code base) problem,
which is why b is such an effective solution.

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).

On Saturday, 19 October 2019 at 15:55:38 UTC, Max Samukha wrote:
> 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

I don't see anything about it in the spec... I wonder if this is legitimately by design or just a plain oversight for all these years.

On Saturday, 19 October 2019 at 17:29:25 UTC, Adam D. Ruppe wrote:
> On Saturday, 19 October 2019 at 15:55:38 UTC, Max Samukha wrote:
>> 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
>
> I don't see anything about it in the spec... I wonder if this is legitimately by design or just a plain oversight for all these years.

Looking at bugzilla there's a lot of issues related with multiple interfaces.

Found one that is similar to this one: https://issues.dlang.org/show_bug.cgi?id=4435

You shouldn't be able to make an ambiguous call like that to begin with.