SE-0169


(Michael M. Mayer) #1

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.mayer6@gmail.com


(Goffredo Marocchi) #2

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.

The goal of progressive disclosure is NOT to reduce the amount of learning you need to get COMPLETE understanding of a topic like access control, but being able to get started easily with a small subset of info and go deeper if you need it and on your terms which this proposal achieves.

···

Sent from my iPhone

On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution <swift-evolution@swift.org> wrote:

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.mayer6@gmail.com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #3

Sent from my iPhone

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.

The goal of progressive disclosure is NOT to reduce the amount of learning you need to get COMPLETE understanding of a topic like access control, but being able to get started easily with a small subset of info and go deeper if you need it and on your terms which this proposal achieves.

Agreed. If this proposal gets accepted, one only needs to learn internal and private to work as an application developer, and only later public and open as a library other. fileprivate can be learned when necessary, in rarer situation.

···

On 11 Apr 2017, at 09:24, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution <swift-evolution@swift.org> wrote:

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.mayer6@gmail.com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution