All - I am not in favor of this change. While I agree that the implementation of fileprivate and open as well as the changes to private had some unintended by-products, they can easily be accommodated. Sometimes the language by its nature dictates style. I say at this point, we all just need to deal with it and move on. We have bigger and more impactful language features to fry.
IMHO the changes in this proposal create a host of complications in the understanding of what can already be a hard to understand topic. We are greatly increasing the surface area of what must be learned in order to completely grok private and fileprivate. This added complexity does not justify what I feel are just cosmetic improvements to suit a particular coding style. Changes such as this to suit a particular coding style, need to be avoided or we risk losing focus on the definition and implementation of more critical changes. I don’t comment on many proposals, but this one stood out as antithetical to the stated goals of the Swift evolution. Regards, Michael ================== Michael M. Mayer Hanover, MD m.may...@gmail.com
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
