> Thanks for refusing to let your pitch die. Something should eventually be > done here and it's good to get feedback. The only reason to bring this up in > Swift 4 is if we decide to outlaw some code pattern that's already in use. If > this ends up just an additive convenience request, than it can be a bug > report for now and come back in Swift 5. There have been a couple +1's > already but I don't know whether it's a serious problem or just an annoyance.
For me, it’s a serious annoyance. A single wrong `mutating` in an API would be a minor issue, but the problem is that it infects the rest of the code like a plague. It’s bad enough that I’ve delayed work on that project, hoping for a resolution. > The problem I have with [SR-4649] "Don't require & to pass value to > UnsafeRawPointer", is that it seeks to create inconsistency between raw and > non-raw pointers. That might make sense for non-homogenous tupes, but > otherwise I don't think it's desirable. If a more consistent fix can be applied also to non-raw pointers, that would be great. That bug documents the problem I ran into, not necessarily the best solution. Others will know better what fits with the future direction of Swift and the underlying implementation. Anders _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
