should new R(arg) be able to run a proc init= ?

[mppf]

Today we have several data structures in the modules that implement both proc init(rhs: rhsType) and proc init=(rhs: rhsType) for a variety of rhsType types. For example, there are these two functions implementing initialization of a list from a range :

chapel/modules/standard/List.chpl

Line 250 in 4ebb0e3

proc init(other: range(?t), param parSafe=false) {

chapel/modules/standard/List.chpl

Line 355 in 4ebb0e3

proc init=(other: range(?)) {

It seems to be unfortunate that these initializers need to be repeated. So, this issue asks two questions:

1. Should it be possible to implement one of these by calling the other? Does it work today to implement init= by calling init? Could we make it possible to implement init by calling init= ? Note that even if simple cases work here, init and init= have different strategies for instantiated or partially instantiated types (init uses additional arguments while init= uses this.type). Do we need some of the strategies from tertiary initializers to do this? (see issue tertiary initializers #17225).
2. Should the compiler automatically enable code like new list(myRange) to run list.init=(rhs: range) if no suitable list.init is available? This question is related to the question of whether or not the compiler can use an init= with an appropriate different type RHS to implement a cast (issue Should the compiler be able to infer implied operations? #17200).

[mppf]

#17200 (comment) discusses a case with list that might be a good motivating example but seems to propose that if one provides proc init(arg) then proc init= is inferred while the above proposes the opposite.