On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
> On Sat, Jun 6, 2020 at 11:21 PM H. S. Teoh via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via Digitalmars-d wrote:
>> > [...]
>>
>> Wasn't Manu one of the people who pushed for @nogc and eventually got it in?
>>
>
> Yes, @nogc is totally my meddling, and it's a very valuable tool! If only we could get a robust ARC solution over the line... ;)
>
> Outside the realtime code though, GC can be useful. It's not bad the language has GC, but it would be nice if @nogc existed much earlier so there was a better culture of writing libraries to support it. Most libraries I've written recently work with or without GC.

To bad that @nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor.

-Alex

On Tue, Jun 9, 2020 at 4:15 AM 12345swordy via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
> > On Sat, Jun 6, 2020 at 11:21 PM H. S. Teoh via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> >
> >> On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via Digitalmars-d wrote:
> >> > [...]
> >>
> >> Wasn't Manu one of the people who pushed for @nogc and eventually got it in?
> >>
> >
> > Yes, @nogc is totally my meddling, and it's a very valuable tool! If only we could get a robust ARC solution over the line... ;)
> >
> > Outside the realtime code though, GC can be useful. It's not bad the language has GC, but it would be nice if @nogc existed much earlier so there was a better culture of writing libraries to support it. Most libraries I've written recently work with or without GC.
>
> To bad that @nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor.
>
> -Alex
>

 What do you mean?

On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:

> I have almost no time recently; work-from-home is hard and I work 12-14
> hours a day to try and make up for lost productivity, and still falling
> behind.

Wow, that sucks. That's not healthy at all. You should come here to Sweden instead and work for DICE :) We care about our employees. Sweden also has one of the world's strongest laws related to employment.

--
/Jacob Carlborg

On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
> On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
>> What are you?
>
> Oops, what about you?

Well, I currently use 2 languages extensively: C# and D. There is not really much contest in which of the two is better when external factors don't push either choice. D code is easier to keep short, easier to modularize and easier to make performant.

Why do I say that D is easier to modularize than C#? Isn't C# suppposed to be a scalable language? A good example is D `x.abs` versus C# `Math.Abs(x)`. In C#, I can only import stuff for the whole file, not just for one function. Also for a static function, C# forces he innermost "module" to be a class, so if I want to split a class in two, I have to change code calling the member functions. In D I can just need to change some imports, since the functions would be module-level.

Can't speak whether I'd prefer D over Rust or Nim since I haven't used either. I suspect they would be around equal overall.

On Tuesday, 9 June 2020 at 12:05:45 UTC, Dukc wrote:
> Also for a static function, C# forces he innermost "module" to be a class, so if I want to split a class in two, I have to change code calling the member functions. In D I can just need to change some imports, since the functions would be module-level.
>

This can be solved with partial classes in C#, can't it?

On Tuesday, 9 June 2020 at 12:05:45 UTC, Dukc wrote:
> On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
>> On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
>>> What are you?
>>
>> Oops, what about you?
>
> Well, I currently use 2 languages extensively: C# and D. There is not really much contest in which of the two is better when external factors don't push either choice. D code is easier to keep short, easier to modularize and easier to make performant.
>
> Why do I say that D is easier to modularize than C#? Isn't C# suppposed to be a scalable language? A good example is D `x.abs` versus C# `Math.Abs(x)`. In C#, I can only import stuff for the whole file, not just for one function. Also for a static function, C# forces he innermost "module" to be a class, so if I want to split a class in two, I have to change code calling the member functions. In D I can just need to change some imports, since the functions would be module-level.
>

You can achieve that with a mix of partial classes and using static, the only downside is a bit more of boilerplate on C# side.

On Tuesday, 9 June 2020 at 00:55:44 UTC, Manu wrote:
> On Tue, Jun 9, 2020 at 4:15 AM 12345swordy via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
>> > [...]
>>
>> To bad that @nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor.
>>
>> -Alex
>>
>
>  What do you mean?

You can't call the destroy function for classes in a @nogc context. The de-constructor is not virtual, because of this, it doesn't inherent the attributes.

-Alex

On 6/9/20 9:54 AM, 12345swordy wrote:
> On Tuesday, 9 June 2020 at 00:55:44 UTC, Manu wrote:
>> On Tue, Jun 9, 2020 at 4:15 AM 12345swordy via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>
>>> On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
>>> > [...]
>>>
>>> To bad that @nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor.
>>>
>>>
>>
>>  What do you mean?
> 
> You can't call the destroy function for classes in a @nogc context. The de-constructor is not virtual, because of this, it doesn't inherent the attributes.

That's true of classes with most attributes in general.

For example, you can't compare objects for equality in @safe code.

This was the point for the ProtoObject idea.

-Steve

On Tuesday, 9 June 2020 at 13:06:30 UTC, Paulo Pinto wrote:
>
> You can achieve that with a mix of partial classes and using static, the only downside is a bit more of boilerplate on C# side.

I thought about this a bit. Perhaps it goes like this: In D, I should split files when I what to split what I export. But in C#, I should split files when I want to split what I import. Meaning, if I have two functions and want to import `System.Collections` for only one of them, I should consider splitting them to different files, using the partial class trick.

Correct?

On Tuesday, 9 June 2020 at 14:08:24 UTC, Steven Schveighoffer wrote:
> On 6/9/20 9:54 AM, 12345swordy wrote:
>> On Tuesday, 9 June 2020 at 00:55:44 UTC, Manu wrote:
>>> On Tue, Jun 9, 2020 at 4:15 AM 12345swordy via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>>
>>>> On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
>>>> > [...]
>>>>
>>>> To bad that @nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor.
>>>>
>>>>
>>>
>>>  What do you mean?
>> 
>> You can't call the destroy function for classes in a @nogc context. The de-constructor is not virtual, because of this, it doesn't inherent the attributes.
>
> That's true of classes with most attributes in general.
>
> For example, you can't compare objects for equality in @safe code.
>
> This was the point for the ProtoObject idea.
>
> -Steve

An idea that show no progress for what? Two years? I am losing my patience with this already. I can't consider d to be a serious language if this bug won't be fix in some reasonable time frame in the future.

-Alex