Hi everybody,

I'm just fiddling around with signals and slots and fell over this nasty bug:

(copied from std.signals)
"Slots can only be delegates formed from class objects or interfaces to class objects. If a delegate to something else is passed to connect(), such as a struct member function, a nested function, a COM interface or a closure, undefined behavior will result."

Is there any chance, that this bug is fixed in the near future ore is it something we have to live with?

On Saturday, 17 October 2020 at 16:22:39 UTC, Johann Lermer wrote:
> Hi everybody,
>
> I'm just fiddling around with signals and slots and fell over this nasty bug:
>
> (copied from std.signals)
> "Slots can only be delegates formed from class objects or interfaces to class objects. If a delegate to something else is passed to connect(), such as a struct member function, a nested function, a COM interface or a closure, undefined behavior will result."
>
> Is there any chance, that this bug is fixed in the near future

No. std.signals is old, old-fashioned but is still there because there's no proposals to replace it and the standards for std are high.

std.signals is there not because it's good but rather for historiacal reasons.

> ore is it something we have to live with?

Likely. But you can work on something better and use it.

On Saturday, 17 October 2020 at 16:36:37 UTC, Basile B. wrote:
> On Saturday, 17 October 2020 at 16:22:39 UTC, Johann Lermer wrote:
>> ore is it something we have to live with?
>
> Likely. But you can work on something better and use it.

There is https://code.dlang.org/packages/phobosx, but I have no experience with it.

Bastiaan.

On Saturday, 17 October 2020 at 16:36:37 UTC, Basile B. wrote:
> No. std.signals is old, old-fashioned but is still there because there's no proposals to replace it and the standards for std are high.

Great. So there's a module in phobos that's not up to phobos' standards and it doesn't get improved, because the standards are too high. That's depressing.

Btw. why is it old-fashioned?

On Sunday, 18 October 2020 at 16:27:43 UTC, Johann Lermer wrote:
> On Saturday, 17 October 2020 at 16:36:37 UTC, Basile B. wrote:
>> No. std.signals is old, old-fashioned but is still there because there's no proposals to replace it and the standards for std are high.
>
> Great. So there's a module in phobos that's not up to phobos' standards and it doesn't get improved, because the standards are too high. That's depressing.
>

It is. std.xml, std.json, std.stream...

The bar was raised in an effort to improve quality but it was done so at the expense of incremental improvements. I.e. it had to be near perfect or nothing. Given the size of the D community it is the latter and Phobos is effectively in maintenance mode.

If D had contributors lining up like say Python then it might be a different story but it doesn't.

> Btw. why is it old-fashioned?

I am only guessing but looking at the module I'd say the way it is structured doesn't fit in with "modern D", i.e. it isn't betterC friendly with @safe and @nogc, liberal use of @property etc.

On 10/18/20 5:53 PM, norm wrote:
> On Sunday, 18 October 2020 at 16:27:43 UTC, Johann Lermer wrote:
>> On Saturday, 17 October 2020 at 16:36:37 UTC, Basile B. wrote:
>>> No. std.signals is old, old-fashioned but is still there because there's no proposals to replace it and the standards for std are high.
>>
>> Great. So there's a module in phobos that's not up to phobos' standards and it doesn't get improved, because the standards are too high. That's depressing.
>>
> 
> It is. std.xml, std.json, std.stream...
> 
> The bar was raised in an effort to improve quality but it was done so at the expense of incremental improvements. I.e. it had to be near perfect or nothing. Given the size of the D community it is the latter and Phobos is effectively in maintenance mode.
> 
> If D had contributors lining up like say Python then it might be a different story but it doesn't.

Well put.

On Sunday, 18 October 2020 at 21:53:06 UTC, norm wrote:

> It is. std.xml, std.json, std.stream...
>
> The bar was raised in an effort to improve quality but it was done so at the expense of incremental improvements. I.e. it had to be near perfect or nothing. Given the size of the D community it is the latter and Phobos is effectively in maintenance mode.

This might all be true, but does it matter? It's open source, so all you have to do is fork Phobos, make the changes you want, and then dump the final result into a package others can use. This can typically be done by editing a single file of source code. I've done it.

Incremental change is not held back by the high standards of Phobos. I don't think it started as a fork of std.xml, but there is https://code.dlang.org/packages/dxml Adding a Dub dependency is a low bar. (And for that matter, you wouldn't even have to use Dub for this purpose, you could just download a file or two and drop them into your project the same as any other D source files.)

On Monday, 19 October 2020 at 14:52:45 UTC, bachmeier wrote:

> This might all be true, but does it matter?

I firmly believe yes, it does matter. A buggy standard library certainly does not help in raising D's attractivness for programmers coming from other languages.

On Tuesday, 20 October 2020 at 07:47:15 UTC, Johann Lermer wrote:
> On Monday, 19 October 2020 at 14:52:45 UTC, bachmeier wrote:
>
>> This might all be true, but does it matter?
>
> I firmly believe yes, it does matter. A buggy standard library certainly does not help in raising D's attractivness for programmers coming from other languages.

I was referring to the part about how development stopped because it has to be perfect to get in. That's not the reason development stops. It stops because nobody wants to write the code. Mark the Phobos library as "do not use" (as has been the case for years with std.xml) and link to Dub projects that provide the functionality. There's no reason anyone needs to rely on Phobos. The programming world isn't perfect.