Added Implicit Initializer proposal #37
Conversation
|
You should address an issue where it is very to hard to discover which code is implicitly converting it. I remember this was big issue for me in Scala where a lot of things are built on implicit behaviour and a lot of types are converted between each other and it starts to get quite complicated once you have modules/namespaces and you need to make sure you import it and also you need make sure you import correct module. |
|
The idea behind this implicit conversion isn't to make things difficult to find rather will only be performed in the context of "safe" environments like Float -> Double so the conversion will be completely transparent and you will never have to track it down. |
|
Interesting you say that, because the implicit conversion between a float and a double actually falls into the "unsafe" behavior category since they vary in precision. On the other hand, implicitly casting a string to an nsurl is exactly the kind of behavior I would love to see. |
|
Maybe that was a bad example I was going for more of Int8 -> Int32 for my example. |
|
If you restrict it to numeric/basic types, then it is fine, I guess. But if you allow any type, it could get easily messy because authors of frameworks will use it. |
|
Discussion should happen on the swift evolution list. |
|
@lattner Where is the mailing list ? The readme rather unhelpfully doesn't have a link to it. |
|
@jcampbell05 here you go ;) |
|
@AlexDenisov Cheers ! |
|
As I noted on the mailing list, I have major concerns about the technical feasibility of this proposal regarding the complexity it would add to the expression type checker (which once tried to support a similar feature and failed). Until we can address the technical concerns sufficiently, we should not bring this proposal up for a review. |
Added a new proposal to allow for implicit initializers based on discussions in the swift-evolution mailing thread.