--- Log opened Thu Aug 14 00:00:11 2025
02:44 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
02:44 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-kernel
06:37 < purpleKarrot> All ownership should be documented from the perspective of the receiver. For return types, "owned" means the caller is responsible for destroying it. If the returned object is owned by the thy library, it needs to be documented as "unowned" from the perspective of the caller. Unowned objects should have type `T const*`. This makes it clear that it cannot be passed to the destructorm which requires `T*`.
06:38 < stickies-v> yup, that's exactly what i'm implementing
06:38 < stickies-v> (at least part of it)
06:47 < TheCharlatan> I feel like documenting it in the API is kind of good enough, but if you're preference would be to go back to type casting, pupleKarrot's current approach would be my preferred route. 
06:49 < stickies-v> with purpleKarrot's approach, do you mean the typesafe mapping from https://github.com/purpleKarrot/btck/blob/master/src/util/type_mapping.hpp, or something else?
06:49 < TheCharlatan> I don't think marking it as const really solves anything, you are just kind of stuck with a concept that you can't cleanly express in both cases. You need some kind of reference wrapper to actually enforce it. My preference is for type casting to avoid any potential future debates about the performance impact of wrapper structs, which is why I initially implemented them like that.
06:50 < TheCharlatan> stickies-v: yes, though I guess that is still not quite perfect, but close enough.
06:51 < stickies-v> yeah i really like the approach of that type mapping, it's a really elegant, clean and looks much safer
06:51 < stickies-v> i'm working on something quite different though, but i'll try and get a gist / some documentation up to describe it better
06:56 < purpleKarrot> TheCharlatan: can you elaborate on "I don't think marking it as const really solves anything"?
06:57 < TheCharlatan> just saying that it doesn't prevent anybody from extending its lifetime, though obviously it communicates intent a bit better.
06:58 < stickies-v> it doesn't make it impossible to abuse, but i've found using constness correctly makes it much easier to build a safe c++ wrapper
07:00 < TheCharlatan> it does?
07:00 < TheCharlatan> (make it easier)? :P
07:04 < purpleKarrot> Not in the sense that less code is required, but in the sense that it is easier to reason about. Yes, I would sign that.
07:06 < TheCharlatan> yeah, that makes sense to me too.
07:06 < stickies-v> definitely wrt reasoning, but i think also wrt amount of code required because it allows much more metaprogramming
07:09 < purpleKarrot> It is important that `const` is used in its abstract meaning. A function `Foo_DoSomething(struct Foo const* self)` should communicate: Calling this function does not change the logical representation of the object Foo. This is especially imprtant because const is not transitive by default in C and C++.
07:12 < TheCharlatan> purpleKarrot why are you mentioning this?
07:17 < purpleKarrot> In the file `bitcoinkernel_wrapper.h` in the PR, there are some member functions that start with `Set` and are marked `const`. Example: `ContextOptions::SetChainParams(ChainParams& chain_params) const`.
07:19 < purpleKarrot> This is bitwise constness. The function does not change the actual data members of the class, which is just a handle. But it changes the logical state of the object.
07:20 < purpleKarrot> Hence, the function should be marked non-const, even though the data members are not modified.
07:22 < purpleKarrot> Also, the C++ wrapper should not use `m_options.get()`, but two implementations of `impl()`, overloaded on its own constness. Then you would actually get a compiler error that the C function requires a different constness.
07:29 < purpleKarrot> Example: https://godbolt.org/z/fzd1Ech36
07:30 < TheCharlatan> nice, thanks for the example :)
07:32 < stickies-v> overview of the ownership semantics i'm working on: https://gist.github.com/stickies-v/db3766418a0c92ba1118ccedcbc3e68e
07:43 < purpleKarrot> stickies-v do you have an implementation to look at?
07:43 < stickies-v> 75% there
08:01 < purpleKarrot> The main difference to my current approach to ownership is that you have explicit `Handle` types. In the C++ wrapper, you use `operator->`, while I use CRTP to allow `operator.`.
08:53 < stickies-v> blockchecked PR: https://github.com/bitcoin/bitcoin/pull/33078
08:55 -!- maxedw [sid625334@id-625334.uxbridge.irccloud.com] has joined #bitcoin-kernel
13:06 -!- Netsplit *.net <-> *.split quits: maxedw, hebasto, purpleKarrot, Anduck, cfields, ryanofsky, laanwj, BlueMatt, _aj_, TheCharlatan,  (+6 more, use /NETSPLIT to show all of them)
13:08 -!- Netsplit over, joins: maxedw, purpleKarrot, fjahr, laanwj, dergoegge, stickies-v, ryanofsky, TheCharlatan, Anduck, lightningbot (+6 more)
14:29 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
--- Log closed Fri Aug 15 00:00:15 2025