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

-- 
MSDOS = MicroSoft's Denial Of Service

On Friday, 18 October 2019 at 16:37:03 UTC, H. S. Teoh wrote:
> On Fri, Oct 18, 2019 at 03:09:02PM +0000, welkam via Digitalmars-d wrote: [...]
>> I have this view. If current libraries or services in all languages do not satisfy your needs and you want to build your own solution then D is the perfect language. If you want to take a bunch of libraries, put some glue code and shit a product then D is a bad language for you.
> [...]
>
> Very interesting view.  This probably explains why I like D so much -- I've never liked the idea of just throwing a bunch of libraries together with some glue code and calling it a product.  But I bet most people would disagree.  *shrug*
>
>
> T

It suppose to be ship not shit...
Its not really interesting. Its just reality. If you want to build iOS game you are forced by circumstances to write it in swift. If you want to make multi platform(PC and consoles) game based on Unreal engine you are forced to use C++. If your program requires certain library you would choose a language that has access to that library. It would be foolish to pick D in those situations. That said if you want to make a server for a game then D start to shine because game server require lots of custom code. When it comes to writing custom code I dont think any language on the market is better than D.

On Thursday, 17 October 2019 at 18:38:31 UTC, Rumbu wrote:
> On Thursday, 17 October 2019 at 17:56:03 UTC, H. S. Teoh wrote:
>> On Thu, Oct 17, 2019 at 04:50:15PM +0000, Rumbu via Digitalmars-d wrote:
>>> On Thursday, 17 October 2019 at 16:26:07 UTC, Atila Neves wrote:
>>> > On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:
>>> > > On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves wrote:
>>> > > There is no language construct to use RAII or heap application on objects. We had scope but it was deprecated.

scope class Foo { ... } was always a bit weird and too narrow a feature. IMO it would have been better to allow aliases to storage classes as a general concept

class _Foo { ... }

alias Foo = scope _Foo;

which I have has to hack LDC to do for `__gshared`.

>>> > That would be news to me. Even if `scope obj = new MyClass;` got deprecated, there are library solutions.
>>> 
>>> Library solution is not a *language construct*. You know what? Let's deprecate 'struct'. I bet that we can build a library solution instead. Too many keywords, 'switch' can be reduced to a library solution using just 'if's.
>>
>> Why does it have to be a language construct? Please explain.
>
> Because library solutions are workarounds and don't highlight any language design commitment. Using library solutions, I can make D look like Brainfuck if I insist. But this doesn't mean that D is Brainfuck. Keep in mind that the original question was why I consider OOP a second hand citizen in D language. I fact the outcome of the discussion does nothing else than strongly support my opinion: I need a library solution to do OOP in D.

What I think was lost in the chain is that it is entirely possible to do

auto foo = Structify!MyClass(args);

as a counterpart to

scope obj = new MyClass;

On Thursday, 17 October 2019 at 19:00:47 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 17 October 2019 at 17:23:29 UTC, welkam wrote:
>> If dichotomy isn't false then answer weather D is high or low level language? The dichotomy exist for other languages because of their design limitations not because of some lows of nature.
>
> Low level.  With some high level runtime features.  There is very little room for high level optimization in D.

I hope for that not to be the case if/when the MLIR SAOC project comes through.

Even without that being able to do array of struct <-> struct of array in the language is very nice and as an example of high level optimisation parameterisation that is far more effective in allow optimisation from the top down and still be able to change design decisions.

Making D the default implementing (or interface) language and C++ interop are faily much the same thing. I read that as you're trying to make us a kind of new C - a langage between most other languages. I must say that I like that direction. As a not-so-big language, ecosystem size tends always to be somewhat of a problem. But interfacing with just about everything, and thus being able to lend other ecosystems should help a lot.

About needing a ridiculously fast interpreter - Are you thinking of using Stefan's newCTFE for that, or does it have to be something else?

On 10/18/19 5:37 PM, Aliak wrote:
> On Friday, 18 October 2019 at 07:56:26 UTC, drug wrote:
>> On 10/17/19 11:48 PM, aliak wrote:
>>> On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker wrote:
>>>> On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:
>>>>
>>>>> [...]
>>>>
>>>> Private to the module *is* correct in D.
>>>>
>>>> http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/
>>>
>>> That's debatable: https://github.com/aliak00/d-isms/blob/master/da-faq/06-access-levels.md
>>
>> You complain that `doAmazingStuff` can access private members of class A if this function and this class are placed together in one module and continue complain that if you put that class in its own module then `doAmazingStuff` now cannot access private members of A and isn't a "first class" citizen of class A. Could you explain you position clearly?
> 
> My position on what? No private access is the consequence of moving a function out of a module.
 That's probably my misunderstanding but I think you took a bad example to show the problem.
You state that:
1) it is bad that `doAmazingWork` has private access to class A members if it is in one module with class A
2) it is bad that `doAmazingWork` has no private access to class A members if it is in an other module than class A

In my opinion these statement are contradictory

On 10/18/2019 7:01 AM, Guillaume Piolat wrote:
> Where is no data or conclusive evidence, there are some anecdotes.
> - some people with large python codebases, even full-time, tend to tell me that dynamic types don't "scale" that well past 10 kLOC
> - some problems reveal themselves "at scale". For example in a C++ constructor you can leave a filed uninitialized. I've once 2 weeks on such a bug that cascaded in a complicated system.  D has .init and would have avoided that.
> - Java seems to scale exceptionally well thanks to a culture of reuse and comparably simple language
> I don't think it's all in our heads that some language are more conducive to "scale", whatever that means.

D does have features specifically to help with scaling. Along with what you mention:

1. modules
2. lack of a global namespace
3. anti-hijacking features
4. a very good capability to do encapsulation
5. the 'version' declaration
6. the 'deprecation' attribute

On 19/10/2019 10:00 PM, Walter Bright wrote:
> On 10/18/2019 7:01 AM, Guillaume Piolat wrote:
>> Where is no data or conclusive evidence, there are some anecdotes.
>> - some people with large python codebases, even full-time, tend to tell me that dynamic types don't "scale" that well past 10 kLOC
>> - some problems reveal themselves "at scale". For example in a C++ constructor you can leave a filed uninitialized. I've once 2 weeks on such a bug that cascaded in a complicated system.  D has .init and would have avoided that.
>> - Java seems to scale exceptionally well thanks to a culture of reuse and comparably simple language
>> I don't think it's all in our heads that some language are more conducive to "scale", whatever that means.
> 
> D does have features specifically to help with scaling. Along with what you mention:
> 
> 1. modules
> 2. lack of a global namespace
> 3. anti-hijacking features
> 4. a very good capability to do encapsulation
> 5. the 'version' declaration
> 6. the 'deprecation' attribute

Don't forget about the 'debug' declaration too!

Highly underutilized that one is, but pretty awesome.

On Saturday, 19 October 2019 at 07:45:14 UTC, drug wrote:
> On 10/18/19 5:37 PM, Aliak wrote:
>> On Friday, 18 October 2019 at 07:56:26 UTC, drug wrote:
>>> On 10/17/19 11:48 PM, aliak wrote:
>>>> On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker wrote:
>>>>> On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:
>>>>>
>>>>>> [...]
>>>>>
>>>>> Private to the module *is* correct in D.
>>>>>
>>>>> http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/
>>>>
>>>> That's debatable: https://github.com/aliak00/d-isms/blob/master/da-faq/06-access-levels.md
>>>
>>> You complain that `doAmazingStuff` can access private members of class A if this function and this class are placed together in one module and continue complain that if you put that class in its own module then `doAmazingStuff` now cannot access private members of A and isn't a "first class" citizen of class A. Could you explain you position clearly?
>> 
>> My position on what? No private access is the consequence of moving a function out of a module.
>  That's probably my misunderstanding but I think you took a bad example to show the problem.
> You state that:
> 1) it is bad that `doAmazingWork` has private access to class A members if it is in one module with class A
> 2) it is bad that `doAmazingWork` has no private access to class A members if it is in an other module than class A
>
> In my opinion these statement are contradictory

Oh. I see. Statement 1 is that it *can* be bad. And for statement 2, I do not think i state anywhere that it’s bad? I can try and rephrase maybe? (Suggestions?)

Some languages have moduleprivate and privateprivate. If D had that then you could actually protect your objects, and if you wanted to allow non-state related variables to only the module you could do that too. So functions can access moduleprivate vars and do things that outside modules couldn’t and variables can be fully protected within a class if need be as well.

On 10/19/19 2:10 PM, Aliak wrote:
> Oh. I see. Statement 1 is that it *can* be bad. And for statement 2, I do not think i state anywhere that it’s bad? I can try and rephrase maybe? (Suggestions?)
> 
> Some languages have moduleprivate and privateprivate. If D had that then you could actually protect your objects, and if you wanted to allow non-state related variables to only the module you could do that too. So functions can access moduleprivate vars and do things that outside modules couldn’t and variables can be fully protected within a class if need be as well.

I agree that in D having private to be in fact moduleprivate is unusual comparing to C++ for example. But is it really bad in practice?