New Issue: Should the compiler be able to infer implied operations?

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).