On the getter/setter: I think the accessor API shape is basically
agreed, and Rene's pybind11 work can ride on top of it rather than
compete with it. I suggest we move that part back to GitHub and unblock
#4099.
The harder question is types. Before mechanics, two questions decide it:
has any user asked for this, and does it make HAL easier to live with.
My honest answer to both is no.
I have not seen anyone on the forum or the list lament conv_. The
documented demand runs the other way: users have asked for wider
integers, 64-bit encoder counts and similar (#3286, the mesa
discussions). And hal_extend_counter, merged two months ago, is integer
wrap reconstruction at the HAL layer, the exact thing we are now told
does not belong there.
I am not defending every conversion. An s32 to float where the value
never nears 2^53 is lossless noise, and I am happy to see those
auto-promoted or narrowed away. What should stay visible are conversions
that carry meaning: float to int where rounding happens, signed to
unsigned where wrap semantics differ, a bit pattern read as a number.
Those are boundaries a user should cross on purpose. The right behavior
there is not a hard no but an explicit step, same philosophy as refusing
to net two outs: surface the decision. Remove that and HAL gets easier
to start and harder to live with; the upfront "you can't do that"
becomes a silent fault three components downstream, the worst kind to debug.
So the real question is governance: the cost of erasing type information
falls on users debugging configs, while the benefit goes to developers
tired of maintaining conv_. Who decides that tradeoff, and on whose behalf?
I am happy to work on narrowing the conversion set and on the accessor
API. On erasing integer types I remain unconvinced, and history is not
encouraging: JavaScript ran on one number type for years and added
BigInt, Lua was double-only until 5.3 added integers back. Everyone who
went all-in on a single fungible number eventually walked it back.
Luca
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
