7 Feb 2025 |
arnetheduck | eh... deprecate the whole thing?
ie this doesn't look like it offers anything on top of =destroy except confusion | 15:19:21 |
arnetheduck | it would be really useful for attaching destructors to specific instances (like std::shared_ptr) but like this? | 15:19:47 |
_araq | people demanded their finalizers to keep working | 15:20:17 |
_araq | but I agree, deprecation would be good | 15:20:30 |
arnetheduck | {.deprecated.} so that they stop? | 15:20:33 |
arnetheduck | bummer the syntax is taken for instance-specifc destructors as well | 15:21:45 |
_araq | proc new(x: var ref T; finalizer) {.deprecated: "use destructors intead".} | 15:41:44 |
_araq | looks pretty easy to do | 15:41:56 |
arnetheduck | no, I mean that an actually useful feature would be to be able to attach a destructor to a specific instance if I'm using a type someone else developed, to have it be called whenever it goes out of complex scope | 15:53:14 |
arnetheduck | indeed, this part is easy and the sooner the better | 15:53:36 |
_araq | yes but you can get that with a custom smart pointer | 15:53:53 |
arnetheduck | I guess that's true also | 15:54:19 |
_araq | the problem with proc new(x: var ref T; finalizer) {.deprecated: "use destructors intead".} is that library authors then have to have two code paths in order to support refc just because somebody might have misused the feature | 15:55:12 |
_araq | and it's not even a clear misuse, maybe somebody typed new(x) out of laziness knowing that somewhere new(x, final) is called making the full type obey anyway | 15:56:18 |
_araq | that's especially true since new(x) has the preferred syntax as x = Myref(...) | 15:56:47 |
arnetheduck | wasn't =destroy called by finalizers at some point? | 15:57:17 |
arnetheduck | * wasn't =destroy called by (the default) finalizers at some point? | 15:58:02 |
_araq | thinking about it | 15:58:48 |
_araq | why not deprecate new entirely, both the normal and the finalizer version | 15:59:11 |
_araq | it predates object construction syntax and is just some crap I took from Pascal | 15:59:38 |
arnetheduck | wfm, I don't like either but people that insist on using result tend to like it | 15:59:55 |
arnetheduck | ie I can't argue against it on semantic grounds, like new(...finalizer) - it's more a style thing | 16:00:26 |
arnetheduck | * ie I can't argue against it on semantic grounds, like new(..., finalizer) - it's more a style thing | 16:00:37 |
_araq | I think we should do this with this .edition thing, opt-in for a modern version of the language that lacks new | 16:01:31 |
arnetheduck | well, we often use proc new(T: type MyType, ...) as a constructor emulator - the "standard" new is more of a hindrance then, if it's called accidentally | 16:02:48 |
_araq | but then we need an edition aware system.nim ... argh... | 16:02:51 |
arnetheduck | deprecating new in system.nim would more or less do that, without the breakage, no? | 16:03:55 |
_araq | it makes people do .push warning:off but yeah it does that | 16:04:34 |
| explosiveend joined the room. | 21:12:00 |
| niminem. changed their display name from Niminem to niminem.. | 22:21:55 |