17200, "mppf", "Should the compiler be able to infer implied operations?", "2021-02-19T18:39:09Z"
This issue is a spin-off from issue #15838.
We have an idea that conversions between types come in 4 levels and a programmer should be able to access any of these 4 levels, but the higher levels imply the lower ones.
- level 4 (implicit conversion) implies 3,2,1 (assign, initialize, cast)
- level 3 (assign) implies 2,1 (initialize, cast)
- level 2 (initialize) implies 1 (cast)
- level 1 (cast) doesn't imply any of the others
Additionally even for the same type, we have the property that assign implies that an init= is available (because some of the assigns will convert to initialization according to split init).
PR #17092 makes it a compilation error to have an init= function with a different RHS type unless there is also a cast function. PR #14956 made it an error to have an assignment function without a corresponding = function (or vice versa).
We made these cases into compilation errors partly under the argument that inferring any implied operations from the operations provided would not be a breaking change.
Should we relax one or more of these cases?
In particular:
- the compiler could use
init=to implement cast between types - the compiler could use default-init/assign to implement init=
It would also be possible for the compiler to infer assign from init= (by deiniting the LHS and then moving in the result of init=). This case is slightly different though because it would not be an error according to the above rules to have init= but not assign and in fact we expect that such a behavior is useful in some cases (possibly with sync variables).