February 27, 2023 Re: D Language Foundation January 2023 Quarterly Meeting Summary | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to bachmeier | On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: >On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: >Razvan submitted a PR deprecating Is there a replacement? Yes. And there always was: In classes this was only an additional way to do, what should better be done with inheritance. | |||
February 27, 2023 Re: D Language Foundation January 2023 Quarterly Meeting Summary | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Dom Disc | On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote: >On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: >On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: >Razvan submitted a PR deprecating Is there a replacement? Yes. And there always was: In classes this was only an additional way to do, what should better be done with inheritance. Generally speaking, I agree, but it does add a little bit of mental overhead for a user if they want to change from struct to class. Hopefully the error message of a class alias this points users in the direction of inheriting instead. | |||
February 27, 2023 Re: D Language Foundation January 2023 Quarterly Meeting Summary | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Dom Disc | On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote: >On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: >On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: >Razvan submitted a PR deprecating Is there a replacement? Yes. And there always was: In classes this was only an additional way to do, what should better be done with inheritance. That is not my understanding from the linked thread. For instance, someone said it can be used as a substitute for multiple inheritance. It seems that anyone using it that way would be losing working code for no reason due to this deprecation. | |||
February 27, 2023 Re: D Language Foundation January 2023 Quarterly Meeting Summary | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to newbie | On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote: >betterC is much more important for some user, please don't phase out BetterC isn’t going anywhere. Too many people use it. | |||
February 28, 2023 Re: D Language Foundation January 2023 Quarterly Meeting Summary | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Mike Parker | On Monday, 27 February 2023 at 23:00:41 UTC, Mike Parker wrote: >On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote: >betterC is much more important for some user, please don't phase out BetterC isn’t going anywhere. Too many people use it. Using word "Too" is scary enough for me here :D | |||
March 01, 2023 Re: D Language Foundation January 2023 Quarterly Meeting Summary | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to bachmeier | On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: >Is there a replacement? If not, why is this even being discussed? I'm all for breaking changes if there's a benefit and an easy path to maintain the existing functionality. This fails on both counts. If you want to enforce that it's not used, add a flag, but don't take it away just for the sake of taking it away. What would be really cool and end-game would be if the gap between druntime and custom runtime such as HipremeEngine would be smoothed out and only one druntime needs to exist. I think this has been the direction for years: ProtoObject, Object.factory, etc. | |||
March 01, 2023 Re: D Language Foundation January 2023 Quarterly Meeting Summary | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Guillaume Piolat | On Wednesday, 1 March 2023 at 13:01:03 UTC, Guillaume Piolat wrote:
> I think this has been the direction for years: ProtoObject, Object.factory, etc.
These things don't really help with it unfortunately, but yes, this is the best goal.
| |||
March 01, 2023 Re: D Language Foundation January 2023 Quarterly Meeting Summary | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Guillaume Piolat | On Wednesday, 1 March 2023 at 13:01:03 UTC, Guillaume Piolat wrote: >On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: >Is there a replacement? If not, why is this even being discussed? I'm all for breaking changes if there's a benefit and an easy path to maintain the existing functionality. This fails on both counts. If you want to enforce that it's not used, add a flag, but don't take it away just for the sake of taking it away. What would be really cool and end-game would be if the gap between druntime and custom runtime such as HipremeEngine would be smoothed out and only one druntime needs to exist. I think this has been the direction for years: ProtoObject, Object.factory, etc. In the experience I got from dealing with the D runtime, this is what I feel like it needs: Compiler could support a flag which is basically saying: User must provide hook functions such as malloc/free, exit(or assert) (those are the most basic ones), for the runtime to work. So, instead of being dropped on a static assertion with plenty of types not found, you get into a runtime error from the features actually being used. That way, no one will ever need to create a custom runtime that does nothing only for the sake of it being compiled. This is all possible to implement too by using weak compiler attribute. The custom runtime I done is roughly 99% of what the current runtime is, the only difference being those allocators and not supporting throw because I don't know how to implement stack rewinding. While that is not done I'll keep maintaining my own for accessing those unimplemented systems. | |||
Permalink
Reply
