Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

I agree with everything you wrote here. And it is for that reason that I
would expect that any future proposal for submodules should be judged in no
small part on its _not_ changing circumstances surrounding access
modifiers, such that no further proposals to revisit this topic will come
up. It's one thing to have one-off discussions to back out a change that in
hindsight seems unwise; it's quite another to have the community return to
the same topic over and over like this. No more. Let's do this never again.
On Fri, Mar 24, 2017 at 00:04 Drew Crawford  wrote:

> Or, since many designs for submodules are possible... confident that
> there will be a good design for submodules
>
> We lack any real information on what Swift designs are possible.  We can
> look to other languages for inspiration but they cannot be transplanted
> wholesale into Swift from a technical, practical, or cultural perspective.
> Rust isn't Swift.
>
> Given, as some have said above, many different submodule designs are
> possible whatever the number of access levels, I would expect that we would
> not revisit this topic again for the foreseeable future, whatever the
> decision is.
>
> I think it would be appropriate to revisit this if we have new
> information.  You have previously argued that there is substantial new
> information which you present as a rationale to revisit it now.  I don't
> accept the premise, but I do accept the argument: if the circumstances
> change it's appropriate to take another look.
>
> On March 23, 2017 at 11:12:32 PM, Xiaodi Wu via swift-evolution (
> swift-evolution@swift.org) wrote:
>
> Or, since many designs for submodules are possible, we can proceed to make
> the best decision *now* with respect to access levels, confident that there
> will be a good design for submodules whether or not there exist both scoped
> and file-based private access. That is to say, any future submodule
> proposal would be judged on how well it accommodates desired use cases if
> one type of private is removed, and any future design for submodules would
> be judged on how well it fits with the current set of access levels without
> duplicating functionality with a different syntax if both types of private
> are retained.
>
> One very important thing about the evolution process (IMO) is that
> decisions made aren't revisited without compelling changes in
> circumstances. It is highly unusual that fileprivate vs. private is now
> going through this process for a _third_ time. I submit that it is
> untenable that every version of Swift should consider a change to the
> access modifiers. Given, as some have said above, many different submodule
> designs are possible whatever the number of access levels, I would expect
> that we would not revisit this topic again for the foreseeable future,
> whatever the decision is. That is, the question being asked here is, is it
> better for Swift to have both fileprivate and private for all time, or one
> file-scoped private for all time?
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

Or, since many designs for submodules are possible... confident that there will 
be a good design for submodules
We lack any real information on what Swift designs are possible.  We can look 
to other languages for inspiration but they cannot be transplanted wholesale 
into Swift from a technical, practical, or cultural perspective.  Rust isn't 
Swift.

Given, as some have said above, many different submodule designs are possible 
whatever the number of access levels, I would expect that we would not revisit 
this topic again for the foreseeable future, whatever the decision is.
I think it would be appropriate to revisit this if we have new information.  
You have previously argued that there is substantial new information which you 
present as a rationale to revisit it now.  I don't accept the premise, but I do 
accept the argument: if the circumstances change it's appropriate to take 
another look.


On March 23, 2017 at 11:12:32 PM, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) wrote:
Or, since many designs for submodules are possible, we can proceed to make the 
best decision *now* with respect to access levels, confident that there will be 
a good design for submodules whether or not there exist both scoped and 
file-based private access. That is to say, any future submodule proposal would 
be judged on how well it accommodates desired use cases if one type of private 
is removed, and any future design for submodules would be judged on how well it 
fits with the current set of access levels without duplicating functionality 
with a different syntax if both types of private are retained.

One very important thing about the evolution process (IMO) is that decisions 
made aren't revisited without compelling changes in circumstances. It is highly 
unusual that fileprivate vs. private is now going through this process for a 
_third_ time. I submit that it is untenable that every version of Swift should 
consider a change to the access modifiers. Given, as some have said above, many 
different submodule designs are possible whatever the number of access levels, 
I would expect that we would not revisit this topic again for the foreseeable 
future, whatever the decision is. That is, the question being asked here is, is 
it better for Swift to have both fileprivate and private for all time, or one 
file-scoped private for all time?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

I would like to separately concur with (most of) Matt's excellent review.  He 
identifies what I think the core issues here, which are
People code in different styles.  A scoped keyword is more useful in some 
styles and less useful in others, and this debate is in many ways a proxy war 
about programming style.
Most of the "solutions" proposed boil down to telling private users to adopt a 
different programming style.  Instead we should be making Swift a great 
language for a *wider* diversity of programming styles as it expands to new 
platforms and solves new problems.
The complexity argument seems weak or even absent.  It consists largely of the 
informal observation that 3 keywords are better than 4, which may "feel true" 
but does not have the research behind it of a Goto Considered Harmful™.  
Instead, most of the research on usage and impact are coming from those trying 
to keep it, which does not seem like their burden to meet.
On March 23, 2017 at 1:22:49 AM, Matt Gallagher via swift-evolution 
(swift-evolution@swift.org) wrote:

> What is your evaluation of the proposal?

I disagree with this proposal. It removes functionality that I actively use.

This proposal aims to revert SE-0025 without really addressing the aims of that 
proposal, merely dismissing the result as "actively harmful" without defining 
what that means. SE-0159 raises the complaint that "private" is syntactically 
more natural default while "fileprivate" is a more useful default. On this 
point, I agree but the proposal is not about mere renaming.

The other discussion in the proposal is to ask the questions:

1. is that distinction between private and fileprivate actively used by the 
larger community of Swift developers

2. if it were used pervasively, would it be worth the cognitive load and 
complexity of keeping two very similar access levels in the language?

Fair questions but despite the proposal claiming "This proposal argues that 
answer to both questions is no", the proposal offers no *arguments* for the 
answers, it merely states a position.

For this reason, I feel the proposal is unreasonably dismissive of the aims of 
SE-0025.

Frankly, both these questions have subjective answers based on how programmers 
tend to design their programs. I personally like to build functionality using 
lots of very tiny types (many just 4 or 5 lines long), therefore, I frequently 
put multiple types in the same file (they're part of the same functionality, 
even if they're not part of the same type). However, I want to have actual 
interfaces and implementation hiding between them otherwise there's always the 
possibility of accidentally abusing the interface to each type. An access 
modifier narrower than the file, like the current scoped "private", is the 
*only* way to achieve this.

Reverting SE-0025 means the only way to have enforced interfaces between types 
is to place them in separate files. This is counterproductive for tiny types 
that form a single conceptual entity. Separate files also requires 
whole-program optimization for optimal performance.

The only conclusion I can make is that programmers in favor of this proposal 
simply don't program this way. However, I find it insulting that this proposal 
is essentially saying: your way of designing and structuring programs is wrong; 
you must use big monolithic types in their own files and endure reduced 
compilation (whole-program optimization) or runtime performance (no inlining 
between files with whole-program off).

I can't help but feel that this proposal is really misdirected frustration. 
Programmers who don't use clusters of tiny types in a single file shouldn't 
care about the existence of a scoped access modifier because it shouldn't 
affect them – they should use file access modifiers and be done. Yet 
apparently, it is file access modifier advocates pushing this proposal.

It really seems like the existence of a scoped access modifier is taking the 
blame for people's frustration that the simpler keyword ("private") is a less 
good default than the clunky keyword ("fileprivate"). I personally agree that 
the behavior or "fileprivate" is probably a better default so I understand the 
desire to give "private" back that meaning again. However, I don't want to lose 
a scoped access modifier because it is *useful* (for reasons of both project 
structure and compilation or runtime performance).

So... thumbs down from me. However, if someone wants to rename fileprivate -> 
private and rename private -> scope (or something) I'd be more supportive.

Regards,
Matt Gallagher.

___
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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Gwynne Raskind via swift-evolution]

Big -1 from me. While I don't like fileprivate at all, removing private as it 
presently exists is not the answer. For details on my thoughts, please refer to 
Drew Crawford's excellent responses to this proposal; he states it far better 
than I ever could :)

-- Gwynne Raskind

> On Mar 20, 2017, at 18:54, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   • What is your evaluation of the proposal?
>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   • Does this proposal fit well with the feel and direction of Swift?
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Carl Brown1 via swift-evolution]

Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs
through March 27, 2017. The proposal is available here:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution<
https://lists.swift.org/mailman/listinfo/swift-evolution>
> or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
>
> Proposal link:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text

> What is your evaluation of the proposal?

-1. No.  Please don't remove a useful feature and break existing code in
thousands of places just to prevent some confusion due to the similarity of
two keywords.

> Is the problem being addressed significant enough to warrant a change to
Swift?

No. Not at all.

> Does this proposal fit well with the feel and direction of Swift?

No. This explicitly removes a feature that the community uses and takes us
back to Swift 2.2. That's literally the opposite of the "direction of
Swift".

> If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I've used a number of different languages with various scoping and access
modifiers, and there is enough variation in other languages that there's no
clear requirement that Swift should agree with any other languages' usage.

> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

I reviewed the usage of `private` and `fileprivate` in the
swift-corelibs-foundation and swift-corelibs-libdispatch repositories.
There are 500+ instances across those two repositories (386 private and 131
fileprivate on the version of those libraries I already had checked out on
my laptop to work on the bug I'm currently chasing).

To be honest, the open-source version of Foundation still has a long way to
go to get the level of quality of the existing Objective-C frameworks, and
we already have enough work to do without having to go make a bunch of
arbitrary changes and risk a bunch of regressions because someone doesn't
like a keyword.  This is a source-breaking change, and we need to stop
making source-breaking changes unless they're absolutely necessary, and
this is far from absolutely necessary.

Accepting this proposal would waste hundreds of person-hours of work and
cause even more confusion than it's trying to prevent by causing tons of
existing online documentation, tutorials and answered questions to be
rendered incorrect.

I vote "No".

-Carl

--
Carl Brown
Swift@IBM
carl.bro...@ibm.com (Work)
ca...@pobox.com (Home)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Add clamp(to:) to the stdlib

[Nicholas Maccharoli via swift-evolution]

Sorry did I skip a step in the proposal process?

On Tue, Mar 21, 2017 at 7:09 PM, Nicholas Maccharoli 
wrote:

> ​Swift-Evolution,
>
> I propose that `clamp(to:)` be added to the standard library as detailed
> in the proposal written below.
> There is also an open pull request to the swift-evolution repository open
> here:
>
> https://github.com/apple/swift-evolution/pull/641
>
> The idea was discussed on previous threads and a few people helped make
> the draft proposal better.
> Since the reception of the ​idea was overall good, I thought it might be
> worth it
> to formally propose the idea.
>
> Please tell me what you think.
>
> - Nick
>
> Add clamp(to:) to the stdlib
>
>- Proposal: SE-
>
> 
>- Authors: Nicholas Maccharoli 
>- Review Manager: TBD
>- Status: Awaiting review
>
> *During the review process, add the following fields as needed:*
>
>- Decision Notes: Rationale
>, Additional
>Commentary 
>- Bugs: SR- , SR-
>
>- Previous Revision: 1
>
> 
>- Previous Proposal: SE-
>
> 
>
>
> 
> Introduction
>
> This proposal aims to add functionality to the standard library for
> clamping a value to a provided Range. The proposed function would allow
> the user to specify a range to clamp a value to where if the value fell
> within the range, the value would be returned as is, if the value being
> clamped exceeded the upper or lower bound in value the value of the
> boundary the value exceeded would be returned.
>
> Swift-evolution thread: Add a clamp function to Algorithm.swift
> 
>
> 
> Motivation
>
> There have been quite a few times in my professional and personal
> programming life where I reached for a function to limit a value to a given
> range and was disappointed it was not part of the standard library.
>
> There already exists an extension to CountableRange in the standard
> library implementing clamped(to:) that will limit the calling range to
> that of the provided range, so having the same functionality but just for
> types that conform to the Comparable protocol would be conceptually
> consistent.
>
> Having functionality like clamped(to:) added to Comparable as a protocol
> extension would benefit users of the Swift language who wish to guarantee
> that a value is kept within bounds, perhaps one example of this coming in
> handy would be to limit the result of some calculation between two
> acceptable numerical limits, say the bounds of a coordinate system.
>
> Proposed
> solution
>
> The proposed solution is to add a clamped(to:) function to the Swift
> Standard Library as an extension to Comparable and Strideable. The
> function would return a value within the bounds of the provided range, if
> the value clamped(to:) is being called on falls within the provided range
> then the original value would be returned. If the value was less or greater
> than the bounds of the provided range then the respective lower or upper
> bound of the range would be returned.
>
> It does not make sense to call clamped(to:) with an empty range,
> therefore calling clamped(to:) and passing an empty range like foo.clamped(to:
> 0..<0) would result in a fatal error.
>
> Given a clamped(to:) function existed it could be called in the following
> way, yielding the results in the adjacent comments:
>
> let foo = 100
> // Closed range variant
> foo.clamped(to: 0...50) // 50foo.clamped(to: 200...300) // 200foo.clamped(to: 
> 0...150) // 100// Half-Open range variant
> foo.clamped(to: 0..<50) // 49foo.clamped(to: 200..<300) // 200foo.clamped(to: 
> 0..<150) // 100
>
>
> Detailed
> design
>
> The implementation of clamped(to:) that is being proposed is composed of
> two protocol extensions; one protocol extension on Comparable and another
> on Strideable.
>
> The 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

Or, since many designs for submodules are possible, we can proceed to make
the best decision *now* with respect to access levels, confident that there
will be a good design for submodules whether or not there exist both scoped
and file-based private access. That is to say, any future submodule
proposal would be judged on how well it accommodates desired use cases if
one type of private is removed, and any future design for submodules would
be judged on how well it fits with the current set of access levels without
duplicating functionality with a different syntax if both types of private
are retained.

One very important thing about the evolution process (IMO) is that
decisions made aren't revisited without compelling changes in
circumstances. It is highly unusual that fileprivate vs. private is now
going through this process for a _third_ time. I submit that it is
untenable that every version of Swift should consider a change to the
access modifiers. Given, as some have said above, many different submodule
designs are possible whatever the number of access levels, I would expect
that we would not revisit this topic again for the foreseeable future,
whatever the decision is. That is, the question being asked here is, is it
better for Swift to have both fileprivate and private for all time, or one
file-scoped private for all time?
On Thu, Mar 23, 2017 at 21:48 Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Mar 23, 2017, at 8:27 PM, Drew Crawford 
> wrote:
>
>
>
>
> Sent from my iPhone
> On Mar 23, 2017, at 6:41 PM, David Hart  wrote:
>
> I have difficulties imagining a submodule proposal that could allow us to
> eliminate fileprivate. Care to give an example?
>
>
> The obvious example would be Rust.  Rust has exactly two visibilities, and
> merely one keyword.  By default, members are "private" which is visible
> inside the module (so, like Swift's internal). The "public" keyword is
> similar to Swift.
>
> The reason this works is that unlike in Swift where a module is something
> like a library or framework (Rust calls those "crates"), in Rust modules in
> are (explicitly) lexically scoped; a "mod myscope {}" module can be created
> for the portion of the file for which the member should be visible and it
> won't be visible outside that scope. Likewise, "fileprivate" can be
> achieved by enclosing the file in a "mod MyFile {}". And like all lexical
> scopes, they can be recursively nested to arbitrary depth to achieve any
> number of visibility behaviors (e.g., declare a module for the first half
> of two files) that would require complex new keywords to achieve in Swift.
>  Finally there are some shortcut features like the ability to infer a
> module structure from the file system.
>
>
> This is a good example of what I meant.  There is an extremely broad range
> of possible designs for submodules.  Some of them, such as this example,
> would make it relatively easy to get by without fileprivate.  There are
> also many other possible designs that would not.
>
> We do not have any idea where Swift will end up yet.  It's not reasonable
> to make any assumptions about what use cases the eventual design might or
> might not address.
>
>
> Then why not leave private and fileprivate alone until we do?
>
> Charles
>
> ___
> 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> On Mar 23, 2017, at 8:27 PM, Drew Crawford  > wrote:
> 
>> 
>> 
>> 
>> Sent from my iPhone
>> On Mar 23, 2017, at 6:41 PM, David Hart > > wrote:
>> 
>>> I have difficulties imagining a submodule proposal that could allow us to 
>>> eliminate fileprivate. Care to give an example?
>> 
>> The obvious example would be Rust.  Rust has exactly two visibilities, and 
>> merely one keyword.  By default, members are "private" which is visible 
>> inside the module (so, like Swift's internal). The "public" keyword is 
>> similar to Swift. 
>> 
>> The reason this works is that unlike in Swift where a module is something 
>> like a library or framework (Rust calls those "crates"), in Rust modules in 
>> are (explicitly) lexically scoped; a "mod myscope {}" module can be created 
>> for the portion of the file for which the member should be visible and it 
>> won't be visible outside that scope. Likewise, "fileprivate" can be achieved 
>> by enclosing the file in a "mod MyFile {}". And like all lexical scopes, 
>> they can be recursively nested to arbitrary depth to achieve any number of 
>> visibility behaviors (e.g., declare a module for the first half of two 
>> files) that would require complex new keywords to achieve in Swift. Finally 
>> there are some shortcut features like the ability to infer a module 
>> structure from the file system. 
> 
> This is a good example of what I meant.  There is an extremely broad range of 
> possible designs for submodules.  Some of them, such as this example, would 
> make it relatively easy to get by without fileprivate.  There are also many 
> other possible designs that would not.  
> 
> We do not have any idea where Swift will end up yet.  It's not reasonable to 
> make any assumptions about what use cases the eventual design might or might 
> not address.

Then why not leave private and fileprivate alone until we do?

Charles

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

Re: [swift-evolution] Proposed amendment to SE-0138: Normalize UnsafeRawBufferPointer Slices

[Karl Wagner via swift-evolution]

Oh, one more thing (about this specific change): If we do this, we should add 
an “offset” parameter to UnsafeMutableBufferPointer.[move]initialize/assign 
(with a default of 0 for source compatibility). Otherwise, it becomes awkward 
to initialise a region of a buffer from another buffer.

What I want to write:
buffer.suffix(from: filled).initialize(from: newData)

If SubSequence is not another unsafe pointer, I’d have to do this:
buffer.baseAddress!.advanced(by: filled).initialize(from: newData)  // Warning: 
deprecated in Swift 4.0

So instead, we should have the ability to write this:
buffer.initialize(startingAt: filled, from: newData) // awkward labels, but src 
compat...

But yeah, this post just reminded me that there are a number of small 
consistency tweaks we could make to the unsafe-buffer API.

- Karl

> On 24 Mar 2017, at 03:22, Karl Wagner  wrote:
> 
> The convenience initialiser should exist on all of the unsafe buffers, not 
> just the raw (untyped) ones.
> 
> I’ve run in to this problem a few times, and I think it would get worse if we 
> adopted a ContiguouslyStored protocol to formalise accessing the raw-pointers 
> of generic collections. It would mean that you couldn’t write code that works 
> with UnsafeRawBufferPointer/Data/DispatchData generically, or with 
> UnsafeBufferPointer/Array.
> 
> Also, there seem to be some implicit conversions for the unsafe-pointer 
> types, but UMBP -> UBP requires an awkward initialiser. We should introduce 
> an implicit conversion for that case or add an “immutable” computed property 
> to UMBP.
> 
> And while we’re on the subject, memory allocation/deallocation functions are 
> weirdly dispersed. In order to allocate an UnsafeMutableBufferPointer, for 
> instance, you have to do:
> 
> var buffer: UnsafeMutableBufferPointer
> init(length: Int) {
>   let b  = UnsafeMutablePointer.allocate(capacity: length)
>   buffer = UnsafeMutableBufferPointer(start: b, count: length)
> }
> 
> Also, the deallocate API feels weird - since it deallocates n items from the 
> head of the pointer, it is a consuming operation and I feel like it should 
> return a new pointer (with @discardableResult). Once you’ve deallocated a 
> memory address, you can never re-allocate that specific location so there is 
> no reason to know about it any more.
> 
> - Karl
> 
>> On 21 Mar 2017, at 03:21, Andrew Trick via swift-evolution 
>> > wrote:
>> 
>> This proposal amends SE-0138: Normalize UnsafeRawBufferPointer Slices
>> to fix a design bug: https://github.com/apple/swift-evolution/pull/651 
>> 
>> 
>> The issue was discussed on swift-evolution in Nov/Dec:
>> See [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029108.html
>>  
>> 
>> 
>> The implementation of this fix is in PR #8222:
>> https://github.com/apple/swift/pull/8222
>> 
>> Fix: Change Unsafe[Mutable]RawBufferPointer's SubSequence type
>> 
>> Original: Unsafe[Mutable]RawBufferPointer.SubSequence = 
>> Unsafe[Mutable]RawBufferPointer
>> 
>> Fixed: Unsafe[Mutable]RawBufferPointer.SubSequence = 
>> [Mutable]RandomAccessSlice
>> 
>> This is a source breaking bug fix that only applies to
>> post-3.0.1. It's extremely unlikely that any Swift 3 code would rely
>> on the SubSequence type beyond the simple use case of passing a
>> raw buffer subrange to an another raw buffer argument:
>> 
>> `takesRawBuffer(buffer[i..> 
>> A diagnostic message now instructs users to convert the slice to a
>> buffer using a `rebasing` initializer:
>> 
>> `takesRawBuffer(UnsafeRawBufferPointer(rebasing: buffer[i..> 
>> To support this, the following `rebasing` initializers are added:
>> 
>> extension UnsafeRawBufferPointer {
>>  public init(rebasing slice: RandomAccessSlice)
>>  public init(
>>rebasing slice: MutableRandomAccessSlice
>>  )
>> }
>> 
>> extension UnsafeMutableRawBufferPointer {
>>  public init(
>>rebasing slice: MutableRandomAccessSlice
>>  )
>> }
>> 
>> The source compatibility test builds are unnaffected by this change.
>> 
>> -Andy
>> ___
>> 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

Re: [swift-evolution] Proposed amendment to SE-0138: Normalize UnsafeRawBufferPointer Slices

[Karl Wagner via swift-evolution]

The convenience initialiser should exist on all of the unsafe buffers, not just 
the raw (untyped) ones.

I’ve run in to this problem a few times, and I think it would get worse if we 
adopted a ContiguouslyStored protocol to formalise accessing the raw-pointers 
of generic collections. It would mean that you couldn’t write code that works 
with UnsafeRawBufferPointer/Data/DispatchData generically, or with 
UnsafeBufferPointer/Array.

Also, there seem to be some implicit conversions for the unsafe-pointer types, 
but UMBP -> UBP requires an awkward initialiser. We should introduce an 
implicit conversion for that case or add an “immutable” computed property to 
UMBP.

And while we’re on the subject, memory allocation/deallocation functions are 
weirdly dispersed. In order to allocate an UnsafeMutableBufferPointer, for 
instance, you have to do:

var buffer: UnsafeMutableBufferPointer
init(length: Int) {
  let b  = UnsafeMutablePointer.allocate(capacity: length)
  buffer = UnsafeMutableBufferPointer(start: b, count: length)
}

Also, the deallocate API feels weird - since it deallocates n items from the 
head of the pointer, it is a consuming operation and I feel like it should 
return a new pointer (with @discardableResult). Once you’ve deallocated a 
memory address, you can never re-allocate that specific location so there is no 
reason to know about it any more.

- Karl

> On 21 Mar 2017, at 03:21, Andrew Trick via swift-evolution 
>  wrote:
> 
> This proposal amends SE-0138: Normalize UnsafeRawBufferPointer Slices
> to fix a design bug: https://github.com/apple/swift-evolution/pull/651
> 
> The issue was discussed on swift-evolution in Nov/Dec:
> See [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029108.html
> 
> The implementation of this fix is in PR #8222:
> https://github.com/apple/swift/pull/8222
> 
> Fix: Change Unsafe[Mutable]RawBufferPointer's SubSequence type
> 
> Original: Unsafe[Mutable]RawBufferPointer.SubSequence = 
> Unsafe[Mutable]RawBufferPointer
> 
> Fixed: Unsafe[Mutable]RawBufferPointer.SubSequence = 
> [Mutable]RandomAccessSlice
> 
> This is a source breaking bug fix that only applies to
> post-3.0.1. It's extremely unlikely that any Swift 3 code would rely
> on the SubSequence type beyond the simple use case of passing a
> raw buffer subrange to an another raw buffer argument:
> 
> `takesRawBuffer(buffer[i.. 
> A diagnostic message now instructs users to convert the slice to a
> buffer using a `rebasing` initializer:
> 
> `takesRawBuffer(UnsafeRawBufferPointer(rebasing: buffer[i.. 
> To support this, the following `rebasing` initializers are added:
> 
> extension UnsafeRawBufferPointer {
>  public init(rebasing slice: RandomAccessSlice)
>  public init(
>rebasing slice: MutableRandomAccessSlice
>  )
> }
> 
> extension UnsafeMutableRawBufferPointer {
>  public init(
>rebasing slice: MutableRandomAccessSlice
>  )
> }
> 
> The source compatibility test builds are unnaffected by this change.
> 
> -Andy
> ___
> 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 23, 2017, at 8:27 PM, Drew Crawford  wrote:
> 
> 
> 
> 
> Sent from my iPhone
> On Mar 23, 2017, at 6:41 PM, David Hart  wrote:
> 
>> I have difficulties imagining a submodule proposal that could allow us to 
>> eliminate fileprivate. Care to give an example?
> 
> The obvious example would be Rust.  Rust has exactly two visibilities, and 
> merely one keyword.  By default, members are "private" which is visible 
> inside the module (so, like Swift's internal). The "public" keyword is 
> similar to Swift. 
> 
> The reason this works is that unlike in Swift where a module is something 
> like a library or framework (Rust calls those "crates"), in Rust modules in 
> are (explicitly) lexically scoped; a "mod myscope {}" module can be created 
> for the portion of the file for which the member should be visible and it 
> won't be visible outside that scope. Likewise, "fileprivate" can be achieved 
> by enclosing the file in a "mod MyFile {}". And like all lexical scopes, they 
> can be recursively nested to arbitrary depth to achieve any number of 
> visibility behaviors (e.g., declare a module for the first half of two files) 
> that would require complex new keywords to achieve in Swift. Finally there 
> are some shortcut features like the ability to infer a module structure from 
> the file system. 

This is a good example of what I meant.  There is an extremely broad range of 
possible designs for submodules.  Some of them, such as this example, would 
make it relatively easy to get by without fileprivate.  There are also many 
other possible designs that would not.  

We do not have any idea where Swift will end up yet.  It's not reasonable to 
make any assumptions about what use cases the eventual design might or might 
not address.

> 
> 
> 
> In Swift, modules are presently tied to libraries/frameworks in a 1:1 way. 
> Because of this we lack the flexibility of recursively nestable modules of 
> other languages and this is the underlying problem that motivates both 
> scoped/private and fileprivate.  If we fixed that, we would actually not need 
> either keyword. 
> 
> http://rustbyexample.com/mod/visibility.html
> https://doc.rust-lang.org/book/crates-and-modules.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

Sent from my iPhone
> On Mar 23, 2017, at 6:41 PM, David Hart  wrote:
> 
> I have difficulties imagining a submodule proposal that could allow us to 
> eliminate fileprivate. Care to give an example?

The obvious example would be Rust.  Rust has exactly two visibilities, and 
merely one keyword.  By default, members are "private" which is visible inside 
the module (so, like Swift's internal). The "public" keyword is similar to 
Swift. 

The reason this works is that unlike in Swift where a module is something like 
a library or framework (Rust calls those "crates"), in Rust modules in are 
(explicitly) lexically scoped; a "mod myscope {}" module can be created for the 
portion of the file for which the member should be visible and it won't be 
visible outside that scope. Likewise, "fileprivate" can be achieved by 
enclosing the file in a "mod MyFile {}". And like all lexical scopes, they can 
be recursively nested to arbitrary depth to achieve any number of visibility 
behaviors (e.g., declare a module for the first half of two files) that would 
require complex new keywords to achieve in Swift. Finally there are some 
shortcut features like the ability to infer a module structure from the file 
system. 



In Swift, modules are presently tied to libraries/frameworks in a 1:1 way. 
Because of this we lack the flexibility of recursively nestable modules of 
other languages and this is the underlying problem that motivates both 
scoped/private and fileprivate.  If we fixed that, we would actually not need 
either keyword. 

http://rustbyexample.com/mod/visibility.html
https://doc.rust-lang.org/book/crates-and-modules.html___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Partial Implementations

[Karl Wagner via swift-evolution]

> On 23 Mar 2017, at 21:36, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Mar 23, 2017, at 11:21 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> 1) Allow stored properties in same-module extensions.  This has been 
>> discussed in the past and is a possibility, but I suspect it is not in scope 
>> for consideration during Swift 4.
> 
> Allowing stored properties and overridable methods in same-*file* extensions 
> would be trivial to implement.
> 
> Same-module extensions are still tricky to generalize because in non-WMO 
> mode, the class (and its metadata, such as stored property layout and vtable) 
> could be emitted in a different translation unit than the extension, so we’d 
> have to ’stitch’ together the definitions somehow and deal with the lack of 
> static knowledge of things like the size of the class and the virtual methods 
> it defines.
> 
> Slava
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I think limiting it to same-file extensions should be enough to handle most 
cases. It’s good that it keeps it local to the original declaration, since it 
would affect things like implicit initialisers.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jarod Long via swift-evolution]

Given that this is such a divisive issue, I'd like to see a revised version of 
this proposal that renames fileprivate back to private but maintains scoped 
access control under a different name like "scoped", as has been suggested. 
That seems like the best compromise -- those that want scoped access control 
can continue to use it, and those that don't can go back to using private.

Jarod

> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> What
>  goes into a review?
>
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
>
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md Thank you,
>
> -Doug
>
> Review Manager


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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

> On Mar 23, 2017, at 10:54 AM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> It is equally frustrating that those on the opposite side of this proposal 
> keep indicating “just don’t pay attention to it” is an acceptable answer to 
> the language growing an entire axis of confusion to its access control (i.e., 
> a wart) so early in its life.

This is because the anti-SE25 camp advance arguments of the form "you can 
replace all your private with fileprivate and it will still work". That is not 
actually true as examples in this thread have shown, but to whatever extent it 
is *typical* it would imply that the programmer does not need to engage with 
the "cognitive load" of private at all because they can simply use fileprivate 
instead. 

I don't find that argument at all convincing, but it does seem clear that if 
one accepts the premise that private is redundant, there would be no need to 
learn what it does. I think it would be better presented as "since there is a 
need to understand what it does, we know it is not redundant."


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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

> But with static linking, your user wouldn’t have to drag 4 .a libraries but 
> only one, which contains all libraries statically linked together.

Static linking is unrelated to merging modules. We can statically link 
libraries on Linux right now, this does not reduce the files on disk or reduce 
the number of statements required to import them etc. 

> Those stats are misleading: an enormous majority of the search results 
> concerning “duplicate symbol” concern incorrect build settings, not a wish to 
> use different versions of the same code.

This is inaccurate, the build settings are workarounds to the problem that 
different versions of the same code (or at least sharing the same C name) are 
in use.  

Swift's visibility is not nearly as configurable as C'a from a build setting 
point of view, although we do have some (e.g. Test mode)



Sent from my iPhone

> On Mar 23, 2017, at 6:52 PM, David Hart  wrote:
> 
> 
>>> On 23 Mar 2017, at 21:49, Drew Crawford  wrote:
>>> 
>>> I'm curious to hear what issue your client had with you using many 
>>> frameworks that static linking doesn't solve.
>> 
>> The issue here is the number of frameworks that the user drags and drops 
>> into Xcode.  Most libraries ship as a single framework, see this page for a 
>> typical example of what the installation documentation for this process 
>> generally looks like.
>> 
>> From a user POV, there is no difference between dragging 4 frameworks and 
>> dragging 4 .a libraries.  Actually, the .a case is worse in Swift because in 
>> addition to object code (.a) we have .swiftmodule, .swiftdoc, and 
>> .modulemap.  So that's a lot of files to drag.
> 
> But with static linking, your user wouldn’t have to drag 4 .a libraries but 
> only one, which contains all libraries statically linked together.
> 
>> I have been involved in generating solutions for this problem in other areas 
>> (see the atbin standard for example) but none of them are supported by Xcode.
>> 
>> Finally, static linking has nothing to do with visibility or the problems of 
>> exposing these frameworks as public API.
>> 
>>> I don't see why submodules could not profit from WMO: the module is still 
>>> compiled all together. Submodules are simply a scoping/hiding mechanism.
>> 
>> Then you will be surprised to hear that this is a subject of some debate.  
>> Relevant thread.
>> 
>>> That looks like a very corner case. I haven't yet found myself in the case 
>>> where I needed multiple versions of a code base in a same product (binary, 
>>> framework, application)
>> 
>> 
>> There are 253 pages of search results for "duplicate symbol" on 
>> StackOverflow.  Compare with 48 pages on fileprivate.  It is quite clear 
>> which is the more complicated feature.
> 
> Those stats are misleading: an enormous majority of the search results 
> concerning “duplicate symbol” concern incorrect build settings, not a wish to 
> use different versions of the same code.
> 
>>> It would be very strange to me if they were independent libraries: what 
>>> would different them from modules then?
>> 
>> The organization of object code on the filesystem does not necessarily have 
>> any relationship to "submodules the philosophical construct".
>> 
>>> But at the same time, we can't write and review proposals with no regard 
>>> for future proposals coming down the road or we end up with a clunky 
>>> language.
>> 
>> 
>> I'm not aware of evidence any submodule proposal is actually coming.  For 
>> example here is the only authoritative statement of the feature, "slated" 
>> for Swift 1.0 , a giant warning that we do not even have a design, and the 
>> doc mostly consists of questions for how the feature should work.
> 
> Well the community has definitely shown a LOT of interest in the topic during 
> the last year. I’d be surprised if a proposal wouldn’t be put through review 
> as soon as it’s “in scope”.
> 
>> A scoped access modifier on the other hand is a feature that was designed, 
>> is implemented, and is now widely used. What you are suggesting is we should 
>> throw it away because at any moment a bird could appear in the bush.
> 
> No. I’m suggesting we throw it away because I argue that it brings more 
> confusion and complexity to the language than it solves problems. Again, I’m 
> not saying you and other people don’t use it: we all have our own development 
> experiences. But that hasn’t stoped us from removing features in the past. 
> The submodule argument was just to mention that it would solve some of the 
> same problems you are solving with scoped-private today.
> 
>> But we've waited for that bird for 3 releases.  Rather, if that bird were to 
>> appear, we could then study whether or not it solves all the problems of the 
>> bird in our hand, or whether it does not.  But that hypothetical is quite 
>> far from the present circumstance.
>>> On March 23, 2017 at 2:02:25 PM, David Hart (da...@hartbit.com) wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[David Hart via swift-evolution]

> On 23 Mar 2017, at 21:49, Drew Crawford  wrote:
> 
>> I'm curious to hear what issue your client had with you using many 
>> frameworks that static linking doesn't solve.
> 
> The issue here is the number of frameworks that the user drags and drops into 
> Xcode.  Most libraries ship as a single framework, see this page 
>  for a typical example of what the 
> installation documentation for this process generally looks like.
> 
> From a user POV, there is no difference between dragging 4 frameworks and 
> dragging 4 .a libraries.  Actually, the .a case is worse in Swift because in 
> addition to object code (.a) we have .swiftmodule, .swiftdoc, and .modulemap. 
>  So that's a lot of files to drag.

But with static linking, your user wouldn’t have to drag 4 .a libraries but 
only one, which contains all libraries statically linked together.

> I have been involved in generating solutions for this problem in other areas 
> (see the atbin standard  for 
> example) but none of them are supported by Xcode.
> 
> Finally, static linking has nothing to do with visibility or the problems of 
> exposing these frameworks as public API.
> 
>> I don't see why submodules could not profit from WMO: the module is still 
>> compiled all together. Submodules are simply a scoping/hiding mechanism.
> 
> Then you will be surprised to hear that this is a subject of some debate.  
> Relevant thread. 
> 
> 
>> That looks like a very corner case. I haven't yet found myself in the case 
>> where I needed multiple versions of a code base in a same product (binary, 
>> framework, application)
> 
> 
> There are 253 pages  of 
> search results for "duplicate symbol" on StackOverflow.  Compare with 48 
> pages  on fileprivate.  It is 
> quite clear which is the more complicated feature.

Those stats are misleading: an enormous majority of the search results 
concerning “duplicate symbol” concern incorrect build settings, not a wish to 
use different versions of the same code.

>> It would be very strange to me if they were independent libraries: what 
>> would different them from modules then?
> 
> The organization of object code on the filesystem does not necessarily have 
> any relationship to "submodules the philosophical construct".
> 
>> But at the same time, we can't write and review proposals with no regard for 
>> future proposals coming down the road or we end up with a clunky language.
> 
> 
> I'm not aware of evidence any submodule proposal is actually coming.  For 
> example here 
>  is the only 
> authoritative statement of the feature, "slated" for Swift 1.0 , a giant 
> warning that we do not even have a design, and the doc mostly consists of 
> questions for how the feature should work.

Well the community has definitely shown a LOT of interest in the topic during 
the last year. I’d be surprised if a proposal wouldn’t be put through review as 
soon as it’s “in scope”.

> A scoped access modifier on the other hand is a feature that was designed, is 
> implemented, and is now widely used. What you are suggesting is we should 
> throw it away because at any moment a bird could appear in the bush.

No. I’m suggesting we throw it away because I argue that it brings more 
confusion and complexity to the language than it solves problems. Again, I’m 
not saying you and other people don’t use it: we all have our own development 
experiences. But that hasn’t stoped us from removing features in the past. The 
submodule argument was just to mention that it would solve some of the same 
problems you are solving with scoped-private today.

> But we've waited for that bird for 3 releases.  Rather, if that bird were to 
> appear, we could then study whether or not it solves all the problems of the 
> bird in our hand, or whether it does not.  But that hypothetical is quite far 
> from the present circumstance.
> On March 23, 2017 at 2:02:25 PM, David Hart (da...@hartbit.com 
> ) wrote:
> 
>> 
>> 
>> On 23 Mar 2017, at 16:49, Drew Crawford > > wrote:
>> 
>>> 
>>> 
>>> 
>>> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com 
>>> ) wrote:
>>> 
 > We will get static linking at some point in the near future.
>>> 
>>> Static linking does not fix this issue. Just change "framework" to ".a".
>>> 
>> I'm curious to hear what issue your client had with you using many 
>> frameworks that static linking doesn't solve.
>> 
 > If we wait until we get submodules, we won't be able to revisit. This is 
 > probably our last chance to "remove" a feature. Submodules can always 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[David Hart via swift-evolution]

> On 23 Mar 2017, at 20:18, Matthew Johnson  wrote:
> 
> 
>> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> On 23 Mar 2017, at 16:49, Drew Crawford > > wrote:
>> 
>>> 
>>> 
>>> 
>>> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com 
>>> ) wrote:
>>> 
 > We will get static linking at some point in the near future.
>>> 
>>> Static linking does not fix this issue. Just change "framework" to ".a".
>>> 
>> I'm curious to hear what issue your client had with you using many 
>> frameworks that static linking doesn't solve.
>> 
 > If we wait until we get submodules, we won't be able to revisit. This is 
 > probably our last chance to "remove" a feature. Submodules can always 
 > add features down the way.
>>> 
>>> Maybe submodules will solve this issue, maybe not.  But submodules are 
>>> *much* more complex than scoped access:
>>> 
>>> * Performance.  This is hot code we compile with WMO.  Moving it into a 
>>> submodule could reduce visibility for optimization in a way that causes a 
>>> performance regression.  In particular, we know that specialization of T is 
>>> a performance requirement, it isn't clear whether that would be preserved.  
>>> Does WMO provide the same visibility across submodules?  Nobody knows.
>>> 
>> I don't see why submodules could not profit from WMO: the module is still 
>> compiled all together. Submodules are simply a scoping/hiding mechanism.
>>> * Namespacing.  It's possible that one program may ship 3-4 versions of 
>>> this code because each dependency has a slightly different version under 
>>> our current samizdat process.  It is not clear whether submodules would 
>>> avoid the "duplicate symbols" issue from C/ObjC.  Xiaodi seems quite 
>>> concerned about a related "duplicate functions" problem involved with 
>>> private today, doubling down on that is not a good idea.
>>> 
>> That looks like a very corner case. I haven't yet found myself in the case 
>> where I needed multiple versions of a code base in a same product (binary, 
>> framework, application)
>>> * It is not clear whether submodules are from an objectcode point of view 
>>> merged into the parent library or kept as individual libraries
>>> 
>> It would be very strange to me if they were independent libraries: what 
>> would different them from modules then? No other language I've used works 
>> that way.
>>> * It is not clear from a .swiftmodule point of view whether submodules are 
>>> merged into the parent module or distributed as .swiftmodules / .swiftdocs
>>> 
>>> * Not clear how much ABI impact there is from submodules at a time when we 
>>> are supposed to be trying to stabilize it
>>> 
>>> I would love to believe that a proposal on submodules will come through 
>>> having solutions to all these issues and many more, then we will implement 
>>> it and all sing kumbayah.  But we are a long distance from that, and it may 
>>> never happen at all, certainly we cannot evaluate proposals that haven't 
>>> been written.  Meanwhile we have a solution in the hand.
>>> 
>> But at the same time, we can't write and review proposals with no regard for 
>> future proposals coming down the road or we end up with a clunky language.
> 
> Or we can just wait until access control and / or submodules are part of a 
> release theme and address these issues more holistically.

Its worth asking the core team, but I have the impression that a submodule 
proposal (Swift 4+ now) will have much less leeway to remove features. So if we 
don’t remove scoped-based private now, we might not be able to remove it later, 
even if we wish we could.

> As I have said before, the details of the submodule design we eventually end 
> up with could influence what problems people want access control to address 
> (or not address).  It’s possible that we could end up with a design that 
> allows us to eliminate `fileprivate` instead of `private` if we feel we must 
> eliminate one of them.

I have difficulties imagining a submodule proposal that could allow us to 
eliminate fileprivate. Care to give an example?

> Right now we just don’t know enough to say for sure.
> 
>> ___
>> 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

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Brad Hilton via swift-evolution]

Big -1 from me. The introduction of private/fileprivate access levels was a 
huge win for Swift 3. I would really hate to see it go.

> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Oliver Jones via swift-evolution]

Fantastic. Great to hear. I look forward to reading the revised proposal!

Regards

> On 24 Mar 2017, at 3:34 am, Itai Ferber  wrote:
> 
> Hi Oliver,
> 
> Thanks for your comments! We thought about this and we agree overall — we 
> will incorporate this suggestion along with others in the next batch update 
> as long as nothing prohibitive comes up.
> 
> — Itai
> 
> On 23 Mar 2017, at 7:49, Oliver Jones wrote:
> 
> Like everyone I’m excited by this new proposal.  But…
> 
> > protocol Codable: Adopted by types to opt into archival. Conformance may be 
> > automatically derived in cases where all properties are also Codable.
> 
> … can I make one suggestion.  Please do not repeat the mistakes of NSCoding 
> in combining the encoding and decoding into a single protocol.  Just as there 
> are Encoder and Decoder classes their should be Encodable and Decodable 
> protocols (maybe have an aggregate Codable protocol for convenience but do 
> not force it).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Partial Implementations

[Vladimir.S via swift-evolution]

On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote:



On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution
 wrote:

MOTIVATION:

In current Swift, a pattern has emerged among some developers, in
order to logically group parts of a class or struct’s declaration,
particularly around protocols:

>> ...


What do you think?


If we wanted to allow code like this to be written we wouldn’t need a
new keyword to do it.  You are proposing two things here:

1) Allow stored properties in same-module extensions.  This has been
discussed in the past and is a possibility, but I suspect it is not in
scope for consideration during Swift 4.


Are we really expect to have stored properties in same-module extensions?
As I remember, there a lot of questions were raised during discussions so 
for some reason *I* had a feeling that we should not expect this happens in 
near feature. Probably I missed something.


FWIW I really like the *feature* proposed to structure declaration of my 
type as I want/need, this leads to more clear and separated code which(at 
declaration level) supports "single responsibility" principle.


I too think that proposed feature should be solved by extensions where 
stored properties are allowed(instead of separate syntax), *but* I believe 
we can(should) have the proposed feature even before we allow(if?) stored 
properties for same-module extensions: allow them for extensions in the 
same *file* only.


It seems like currently file is treated as code unit(especially when we are 
reverting back meaning of 'private' to same-file), which should be 
controlled by single person or contains not too complex logic so can be 
supported by different developers, inside which details should not be 
hidden and "you know what you do". So, IMO it will be naturally if compiler 
allows stored properties for extensions in same file with type declaration 
and treat these extensions just as partial class declaration.


> 2) Change the meaning of

`private` to not mean lexical scope anymore, but instead be lexical
scope or an extension of the type introducing the lexical scope in the
same module.  Changes to access control other than the proposal
currently under review are out of scope for Swift 4.




Charles

___ 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


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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Jonathan Hull via swift-evolution]

Let me vote +1 for splitting it.  The added conceptual complexity should be 
minimal, since it is progressively disclosed.  You only need to know about 
codeable, unless you run into the issue where you only want one, at which point 
stack overflow, etc… will point you to Encodable/Decodable and you will be glad 
they exist.


> On Mar 23, 2017, at 11:44 AM, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi Oliver,
> 
>> On Mar 23, 2017, at 7:55 AM, Oliver Jones via swift-evolution 
>> > wrote:
>> 
>> Like everyone I’m excited by this new proposal.  But…
>> 
>> > protocol Codable: Adopted by types to opt into archival. Conformance may 
>> > be automatically derived in cases where all properties are also Codable.
>> 
>> … can I make one suggestion.  Please do not repeat the mistakes of NSCoding 
>> in combining the encoding and decoding into a single protocol.  Just as 
>> there are Encoder and Decoder classes their should be Encodable and 
>> Decodable protocols (maybe have an aggregate Codable protocol for 
>> convenience but do not force it).
>> 
>> My reasoning:
>> 
>> Sometimes you only want to decode or encode and object and not vice versa.  
>> This is often the case with Web APIs and JSON serialisation.  
>> 
>> Eg:
>> 
>> Often an app only consumes (decodes) JSON encoded objects and never writes 
>> them out (a read only app for example). So the encode(to:) methods are 
>> completely redundant and someone adopting Codable should not be forced to 
>> write them.  
>> 
>> If only I had a dollar for all the times I’ve seen this sort of code in 
>> projects:
>> 
>> class MyClass : NSCoding {
>> init?(coder: NSCoder) {
>>   // ... some decoding code
>> }
>> 
>> func encode(with aCoder: NSCoder) {
>>preconditionFailure(“Not implemented”)
>> }
>> }
>> 
>> 
>> Another example: 
>> 
>> Web APIs often take data in a different structure as input (i.e. “Request” 
>> objects) than they output.  These request objects are only ever encoded and 
>> never decoded by an application so implementing init(from:) is completely 
>> redundant.
>> 
>> Personally I think the approach taken by libraries like Wrap 
>> (https://github.com/johnsundell/wrap ) 
>> and Unbox (https://github.com/JohnSundell/Unbox 
>> ) is a much better design.  Encoding 
>> and decoding should not be the same protocol.
>> 
>> Yes I understand that Codable could provide no-op (or preconditionFailure) 
>> protocol extension based default implementations of init(from:) and 
>> encode(to:) (or try to magic up implementations based on the Codable nature 
>> of public properties as suggested in the proposal) but to me that seems like 
>> a hack that is papering over bad design.  I think this joint Codable design 
>> probably fails the Liskov substitution principle too.
>> 
>> So I again implore you to consider splitting Codable into two protocols, one 
>> for encoding and another for decoding.
>> 
>> Sorry if I’m repeating what other people have already said.  I’ve not read 
>> every response to this proposal on the list.
>> 
>> Regards
> 
> Thanks for your feedback. We are indeed considering splitting this up into 3 
> protocols instead of 1 (“Encodable", “Decodable", "Codable : Encodable, 
> Decodable”).
> 
> The main counterpoint is the additional complexity inherent in this approach. 
> We are considering if the tradeoff is worth it.
> 
> - Tony
> 
> 
> ___
> 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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Slava Pestov via swift-evolution]

We could spell the new attribute @objcMembers or something like that.

Slava

> On Mar 23, 2017, at 10:03 AM, Jordan Rose  wrote:
> 
> What happens for people using @objc to choose the class's runtime name? It 
> seems unfortunate to conflate that with changed inference.
> 
> Jordan
> 
> 
>> On Mar 23, 2017, at 02:11, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> A further benefit of this scheme is that it makes the behavior of @objc on 
>> class members consistent between NSObject-derived and Swift-native classes. 
>> Right now, it is legal to apply @objc to a _member_ of a Swift-native class; 
>> this is what allows Swift-native classes to model @objc protocols and so on. 
>> But of course we don’t ever implicitly infer @objc on members of 
>> Swift-native classes just based on the calling convention of a method.
>> 
>> So now we could say that members of non-@objc classes only infer @objc if 
>> necessary to fulfill an override or protocol requirement, independently of 
>> whether the class is NSObject-derived or not; and @objc can now be applied 
>> to an entire class, as long as its NSObject-derived, to get the implicit 
>> inference behavior on members.
>> 
>> Slava
>> 
>>> On Mar 23, 2017, at 2:06 AM, Slava Pestov  wrote:
>>> 
>>> Here’s an idea for working around the problem of the lack of static 
>>> knowledge during migration. Probably it’s kind of tacky and won’t get much 
>>> traction in it’s current form, but it might start some useful discussion at 
>>> least.
>>> 
>>> Right now, @objc when applied to a _class_ is completely useless; if a 
>>> class ultimately inherits from NSObject, it is always implicitly @objc, and 
>>> applying @objc to a class not rooted in NSObject is always an error. (I 
>>> think at some point in the past we allowed @objc classes that _don’t_ 
>>> inherit from NSObject, but I don’t know if that even made it into any 
>>> released version of Swift, so it’s totally vestigial at this point.) We can 
>>> keep this behavior in Swift 3 mode, but in Swift 4 mode, change things so 
>>> that @objc applied to a class enables @objc inference for the members of 
>>> the class, and the absence of @objc enables the new, more limited inference 
>>> behavior outlined in this proposal.
>>> 
>>> Then the migration story can just be “slap @objc on every NSObject-derived 
>>> class and you’re good”. Existing mixed source bases, KVC, and so on would 
>>> just work. We could also say that in Swift 4 mode, @objc on an 
>>> NSObject-derived class produces a warning asking the developer to consider 
>>> making individual members @objc as necessary instead. This would allow a 
>>> Swift 4 migration to proceed in two phases — first fix any fallout from 
>>> SE-0110 or new string stuff or whatever, and get a working app that builds 
>>> and runs in Swift 4 mode, albeit with some warnings. Then they can deal 
>>> with marking individual class members as @objc later. We could still have 
>>> the option of making it an error to apply @objc to an entire class in a 
>>> future release of Swift, if we decide it is beneficial to do so.
>>> 
>>> Based on feedback, the all-or-nothing nature of the Swift 2->3 migration 
>>> was rather painful — mixing and matching 3 and 4 modules will definitely 
>>> help us do better the next time around, and allowing a complex change such 
>>> as this one to be done piecemeal could be a further step in the right 
>>> direction.
>>> 
>>> Slava
>>> 
 On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
  wrote:
 
 Hello Swift community, 
 
 The review of "SE-0160: Limiting @objc inference" begins now and runs 
 through March 28. The proposal is available here:
 

 https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md
 
 Reviews are an important part of the Swift evolution process. All reviews 
 should be sent to the swift-evolution mailing list at:
 
https://lists.swift.org/mailman/listinfo/swift-evolution
 
 or, if you would like to keep your feedback private, directly to the 
 review manager. 
 
 
 What goes into a review?
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and, eventually, determine the direction of 
 Swift. When writing your review, here are some questions you might want to 
 answer in your review:
 
 * What is your evaluation of the proposal?
 * Is the problem being addressed significant enough to warrant a change to 
 Swift?
 * Does this proposal fit well with the feel and direction of Swift?
 * If you have you used other languages or libraries with a similar 
 feature, how do you feel that this proposal compares to those?
 * How much effort did you put into your review? A glance, a quick reading, 
 or an 

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Jonathan Hull via swift-evolution]

> On Mar 23, 2017, at 1:46 AM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> [Proposal: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md]
>> 
>> I'm definitely in favor of this. Apart from the various motivations 
>> discussed in the proposal, this also allows some changes that could improve 
>> incremental builds: the generated header ("MyApp-Swift.h") wouldn't need to 
>> be regenerated nearly as often with fewer methods exposed to Objective-C. 
>> (There's some nuance here that I don't need to go into right now, and there 
>> are alternate solutions to that problem, but it's nice that the common case 
>> will just put fewer declarations into the header and therefore it would 
>> change less often.)
>> 
>> The migration aspect is a little scary. #selector's Objective-C equivalent 
>> is @selector, which is easy to search for, but #keyPath maps to plain old 
>> strings.
> 
> Are these strings usually literal strings that are passed in to some set of 
> mostly-known selector names, or do people pass them around or even construct 
> them dynamically?

I have cases where I read the strings in from a plist or json, and then use 
them to bind the model with the UI (which may have been auto generated).  For 
example, I have a file which defines a UI which should be dynamically 
generated, and then binds the generated interface to a facade which talks to a 
database (performing any conversions necessary to make the connections work).  
That way, I can add new types of things simply by adding a plist to my app 
(which is much easier and less error prone than hand coding each sub-UI)

I have been experimenting with doing this in a swift-ier way lately, with some 
success, but it is still much more complex and finicky than the ObjC way.

Thanks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 23, 2017 at 12:32:38 PM, Brent Royal-Gordon (br...@architechies.com) 
wrote:

To what extent could your need for safety be satisfied by (a) giving the 
property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a 
very small unit test/shell script/Perl script which makes sure references to 
that very unique name only appear between the two "MARK:" comments?
A third-party linter to get a scoped feature is our current candidate for 
reimplementing this feature if it's dropped from Swift.

However, I think it's worth asking to what extent it makes sense to build a 
language that gets fixed with linters.  For example Swift could have used a 
linter for typechecking (Python is doing this) but the benefits of compile-time 
typechecking affect a large number of programs and so we decided to ship with 
batteries included.

The scoped visibility is like the type system.  It is a compile-time check that 
is used to catch threading, information disclosure, encapsulation violation, or 
similar bugs.  These are problems that affect a large number of programs, we 
should ship with batteries included.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

I'm curious to hear what issue your client had with you using many frameworks 
that static linking doesn't solve.

The issue here is the number of frameworks that the user drags and drops into 
Xcode.  Most libraries ship as a single framework, see this page for a typical 
example of what the installation documentation for this process generally looks 
like.

>From a user POV, there is no difference between dragging 4 frameworks and 
>dragging 4 .a libraries.  Actually, the .a case is worse in Swift because in 
>addition to object code (.a) we have .swiftmodule, .swiftdoc, and .modulemap.  
>So that's a lot of files to drag.

I have been involved in generating solutions for this problem in other areas 
(see the atbin standard for example) but none of them are supported by Xcode.

Finally, static linking has nothing to do with visibility or the problems of 
exposing these frameworks as public API.

I don't see why submodules could not profit from WMO: the module is still 
compiled all together. Submodules are simply a scoping/hiding mechanism.

Then you will be surprised to hear that this is a subject of some debate.  
Relevant thread.

That looks like a very corner case. I haven't yet found myself in the case 
where I needed multiple versions of a code base in a same product (binary, 
framework, application)

There are 253 pages of search results for "duplicate symbol" on StackOverflow.  
Compare with 48 pages on fileprivate.  It is quite clear which is the more 
complicated feature.

It would be very strange to me if they were independent libraries: what would 
different them from modules then?

The organization of object code on the filesystem does not necessarily have any 
relationship to "submodules the philosophical construct".

But at the same time, we can't write and review proposals with no regard for 
future proposals coming down the road or we end up with a clunky language.

I'm not aware of evidence any submodule proposal is actually coming.  For 
example here is the only authoritative statement of the feature, "slated" for 
Swift 1.0 , a giant warning that we do not even have a design, and the doc 
mostly consists of questions for how the feature should work.

A scoped access modifier on the other hand is a feature that was designed, is 
implemented, and is now widely used. What you are suggesting is we should throw 
it away because at any moment a bird could appear in the bush.

But we've waited for that bird for 3 releases.  Rather, if that bird were to 
appear, we could then study whether or not it solves all the problems of the 
bird in our hand, or whether it does not.  But that hypothetical is quite far 
from the present circumstance.
On March 23, 2017 at 2:02:25 PM, David Hart (da...@hartbit.com) wrote:



On 23 Mar 2017, at 16:49, Drew Crawford  wrote:




On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote:

> We will get static linking at some point in the near future.
Static linking does not fix this issue. Just change "framework" to ".a".

I'm curious to hear what issue your client had with you using many frameworks 
that static linking doesn't solve.

> If we wait until we get submodules, we won't be able to revisit. This is 
> probably our last chance to "remove" a feature. Submodules can always add 
> features down the way.
Maybe submodules will solve this issue, maybe not.  But submodules are *much* 
more complex than scoped access:

* Performance.  This is hot code we compile with WMO.  Moving it into a 
submodule could reduce visibility for optimization in a way that causes a 
performance regression.  In particular, we know that specialization of T is a 
performance requirement, it isn't clear whether that would be preserved.  Does 
WMO provide the same visibility across submodules?  Nobody knows.

I don't see why submodules could not profit from WMO: the module is still 
compiled all together. Submodules are simply a scoping/hiding mechanism.
* Namespacing.  It's possible that one program may ship 3-4 versions of this 
code because each dependency has a slightly different version under our current 
samizdat process.  It is not clear whether submodules would avoid the 
"duplicate symbols" issue from C/ObjC.  Xiaodi seems quite concerned about a 
related "duplicate functions" problem involved with private today, doubling 
down on that is not a good idea.

That looks like a very corner case. I haven't yet found myself in the case 
where I needed multiple versions of a code base in a same product (binary, 
framework, application)
* It is not clear whether submodules are from an objectcode point of view 
merged into the parent library or kept as individual libraries

It would be very strange to me if they were independent libraries: what would 
different them from modules then? No other language I've used works that way.
* It is not clear from a .swiftmodule point of view whether submodules are 
merged into the parent module or 

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

[Slava Pestov via swift-evolution]

> On Mar 23, 2017, at 10:47 AM, Philippe Hausler  wrote:
> 
> 
>> On Mar 23, 2017, at 10:14 AM, Jordan Rose > > wrote:
>> 
>>> 
>>> On Mar 23, 2017, at 09:05, Joe Groff via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution 
 > wrote:
 
 
> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution 
> > wrote:
> 
> Alternatives considered
> 
> Do nothing and continue to accept this implicit conversion.
 
 One alternative would be to import CFArray as a typealias for NSArray, 
 etc, erasing the distinction between the two types completely. I did 
 suggest this to Jordan at one point and he pointed out some problems, but 
 I don’t remember them now. Hopefully Jordan can chime in.
>>> 
>>> I'd prefer this solution as well, especially since toll-free bridged CF 
>>> types are nearly indistinguishable from their NS counterparts at runtime, 
>>> so trying to maintain the distinction for dynamic casts or reflection has 
>>> historically been problematic. Part of the problem is that, as Charlie 
>>> noted, CFArray/Dictionary/Set can take an arbitrary set of retain/release 
>>> callbacks, in which case the resulting container isn't fully 
>>> NSArray-compatible. I'm not sure that happens often enough with CF 
>>> containers in the SDKs that accounting for that case is worth the burden of 
>>> separating the types.
>> 
>> [adding Philippe, who has also thought about this problem]
>> 
>> The abstract problems I know of are:
>> 
>> (1) custom callbacks
>> (2) it's legal to import CF without importing Foundation
>> (3) CF types will not get generics
>> 
>> In practice, (1) is both exceedingly rare (only one public API that I know 
>> of) and something that can be worked around by using the CF APIs on the 
>> array—that is, we can keep CFArrayGetValueAtIndex around and just have it 
>> take an NSArray. (2) is something we can deprecate and/or fix. (3) just 
>> means we have to import the CFArray as NSArray rather than Array.
>> 
>> We would have to be very sure that all toll-free bridged CF types are marked 
>> as such; adding toll-free bridging would not be a backwards-compatible 
>> change since it would conflate two types into one. This leads us to a fourth 
>> problem: this is a source-breaking change if anyone has overloads for both 
>> CFArray and NSArray, or adds a protocol to CFArray that NSArray already has. 
>> We probably already need to solve the latter in some way, and could try to 
>> cross our fingers about the former.
>> 
>> Jordan
> 
> 
> I think there are a bit more ramifications that are under the hood here; we 
> should consider the full extent of what changing the behavior between CF 
> types and NS types a bit more deeply than just a cursory proposal. 
> Additionally as with any change to Foundation and CoreFoundation this should 
> be passed around internally to the appropriate stakeholders that will be in 
> charge of providing long term support for any sort of change this would apply 
> to.
> 
> As an initial gut reaction; I would say that this is well past our stage for 
> changes for Foundation and I would hate to see something be pushed out last 
> minute that takes away development time from other important tasks on the 
> table.

What is the fallout you expect from this change in Foundation? On Linux 
codelibs-foundation, there already is no toll-free bridging AFAIK and the CF* 
types are not exposed at all. In the Foundation overlay on Darwin, the 
migration can be mostly automatic, inserting ‘as’ casts in the appropriate 
places where the implicit conversion is taking place now.

I guess there will be some impact on documentation and sample code?

Slava

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

Re: [swift-evolution] Pitch: Partial Implementations

[Slava Pestov via swift-evolution]

> On Mar 23, 2017, at 11:21 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 1) Allow stored properties in same-module extensions.  This has been 
> discussed in the past and is a possibility, but I suspect it is not in scope 
> for consideration during Swift 4.

Allowing stored properties and overridable methods in same-*file* extensions 
would be trivial to implement.

Same-module extensions are still tricky to generalize because in non-WMO mode, 
the class (and its metadata, such as stored property layout and vtable) could 
be emitted in a different translation unit than the extension, so we’d have to 
’stitch’ together the definitions somehow and deal with the lack of static 
knowledge of things like the size of the class and the virtual methods it 
defines.

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution 
>  wrote:
> 
> 
>> On 21 Mar 2017, at 08:05, Rien  wrote:
>> 
>> +1
> 
> -1: I have revised my opinion.
> 
> 
>> 
>>> • What is your evaluation of the proposal?
>> 
>> Makes the language easier to understand, lowers cognitive load during coding.
>> I also hope this will pave the way for a overhaul of the access level system 
>> including modularization.
> 
> I still hope that fileprivate will be dumped one day. Presumably when a 
> better proposal is on the table.
> However it is clear that for some people the disadvantage of dropping it now 
> is bigger than the advantage to the proponents together.
> Regardless of wether the need is only perceived or not.
> 
>> 
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> yes.
> 
> yes, but not without an alternative solution in place at the time fileprivate 
> is dropped.

Can you clarify what you mean here? 

> 
> 
>> 
>>> • Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes
> 
> Yes
> 
>> 
>>> • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>> 
>> private vs fileprivate seems swift-only, as such I have no comparison.
> 
> Same
> 
>> 
>>> • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> 
>> Followed and participated in the discussions.
> 
> 
> Same.
> 
>> 
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>>> through March 27, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. When replying, please try to keep the proposal link at the top of 
>>> the message:
>>> 
>>> Proposal link:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>> Reply text
>>> Other replies
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>> • What is your evaluation of the proposal?
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>> • Does this proposal fit well with the feel and direction of Swift?
>>> • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>> • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> More information about the Swift evolution process is available at
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>> Thank you,
>>> 
>>> -Doug
>>> 
>>> Review Manager
>>> 
>>> ___
>>> 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

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

Re: [swift-evolution] Pitch: Partial Implementations

[Jonathan Hull via swift-evolution]

-1

I would much rather see the ability to introduce stored properties in 
extensions (within the module) + simple file-based submodules.

Also, I think you are missing important parts of the extensions + fileprivate 
pattern.  Sure, a big part of it is being able to group conformances together 
in code.  But another large part is being able to group related code across 
classes and structs (avoiding the need for “friends”).

It would not, as you say, completely eliminate fileprivate from my code, it 
would just further complicate things by having to remember to use a different 
keyword (‘partial’) when I needed storage in extensions.

There have been a few proposals now, where I think the core idea was to enforce 
best practices from another language.  But these end up being harmful (despite 
good intentions) because swift is a different beast, and thus will have 
different best practices.  In particular, extensions allow cross-cutting 
concerns to be placed together.  I can have a little bit of this class and a 
little bit of that one. That leads to different opportunities and challenges 
than those found in languages where a class has to be defined in one place, and 
it means we need different solutions…

As you say, we do have an issue of very large files being created right now, 
but there isn’t a type/scope-based solution which will actually fix that, 
because they all block those cross-cutting concerns. I suspect this will stop 
being an issue once we have both submodules and stored properties in extensions 
(which have both been listed as likely enhancements, but out of scope for Swift 
4).


> On Mar 23, 2017, at 11:12 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> MOTIVATION:
> 
> In current Swift, a pattern has emerged among some developers, in order to 
> logically group parts of a class or struct’s declaration, particularly around 
> protocols:
> 
> class Foo {
>   …
> }
> 
> extension Foo: SomeProtocol {
>   ...
> }
> 
> extension Foo: SomeOtherProtocol {
>   ...
> }
> 
> This has certain appealing characteristics; in addition to the obvious 
> organizational property, this pattern also keeps protocol implementations 
> close to the declaration of conformance to the protocol. Unfortunately, there 
> are a couple of problems:
> 
> 1. Extensions cannot contain stored properties. This means that if a protocol 
> requires a property, and it makes sense for that property to be stored, its 
> conformance cannot be completely contained within the extension, but rather 
> some of it must be in the main declaration.
> 
> 2. It’s not uncommon for these protocol conformances to need access to the 
> type’s private internal state, but extensions do not have access to private 
> members within the state. This necessitates declaring the needed state as 
> fileprivate rather than private, a fact has been a primary rallying point in 
> the battle that’s currently raging on this mailing list over whether we 
> should keep the ‘private’ access modifier, and which I would surmise is 
> probably the major remaining use of ‘fileprivate’ in modern Swift code.
> 
> 3. Since members that are declared ‘fileprivate’ cannot be accessed outside 
> the file, these protocol conformance extensions must belong to the same file 
> as the original declaration, which can lead to very long file sizes when the 
> code to implement a protocol is very long, or when a type supports a large 
> number of protocols.
> 
> PROPOSED SOLUTION:
> 
> Add a keyword to declare only part of a type’s implementation. I am 
> suggesting ‘partial’ as the keyword, but this can be changed for a better 
> name if needed. Partial conformances would be declared like this:
> 
> class Foo {
>   private func somePrivateMethod() { … }
> }
> 
> partial Foo: SomeProtocol {
>   var someRequiredProperty: Int = 5
> 
>   func someRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> partial Foo: SomeOtherProtocol {
>   func someOtherRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> When compiling this, the compiler would simply treat all the contents of 
> partial declarations as if they were located within the original declaration, 
> making the above equivalent to this:
> 
> class Foo: SomeProtocol, SomeOtherProtocol {
>   private func somePrivateMethod() { … }
> 
>   var someRequiredProperty: Int = 5
> 
>   func someRequiredMethod() {
>   self.somePrivateMethod()
>   }
> 
>   func someOtherRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> Obviously, partial declarations would only be allowed within the same module 
> (or submodule, once we get them) as the original declaration.
> 
> The advantages to this approach are:
> 
> 1. Given a pattern that many developers are adopting, this proposal would 
> provide a mechanism to follow that pattern properly instead of repurposing a 
> 

Re: [swift-evolution] Pitch: Partial Implementations

[Charles Srstka via swift-evolution]

> On Mar 23, 2017, at 2:45 PM, Matthew Johnson  wrote:
> 
> Sure, but this does effectively violate lexical scope boundaries as they 
> exist in the original source.

If the yeas have it on SE-0159, and “private” is turned into “fileprivate”, the 
lexical scope boundaries of *everything* will be violated as they exist in the 
original source.

Charles

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

Re: [swift-evolution] Pitch: Partial Implementations

[Matthew Johnson via swift-evolution]

> On Mar 23, 2017, at 2:37 PM, Charles Srstka  wrote:
> 
>> On Mar 23, 2017, at 2:15 PM, Matthew Johnson > > wrote:
>> 
>> What I’m suggesting is that we could accomplish the same functionality by 
>> enhancing extensions.  You can make a case that using a different keyword 
>> for same-module extensions that are allowed to have stored properties is a 
>> good idea.  I’m not sure I would support that though.
> 
> The problem is that people are using extensions to implement part of the 
> original class definition. Part of what is making that pattern awkward is 
> that private members are not accessible from the extensions. Given the 
> SE-0159 discussion, it appears that there is a non-negligible threat of 
> losing the very ability to have scoped members at all if we don’t think of a 
> better alternate solution.
> 
>>> 2) I’m not proposing changing the meaning of ‘private’ here. Since partial 
>>> implementations would all glom into one lexical scope, all the current 
>>> access control rules would apply as they currently do. This is simply a way 
>>> to write a class or struct declaration in multiple parts, without having to 
>>> use extensions.
>> 
>> This does not fit with any definition of “lexical scope” I am familiar with. 
>>  I wouldn’t want to see Swift adopt this definition of lexical scope.
> 
> No definitions required. All I’m proposing is basically preprocessing the 
> thing into one type declaration.
> 
> class Foo {
>   func bar() {}
> }
> 
> partial Foo {
>   func baz() {}
> }
> 
> just becomes syntactic sugar for:
> 
> class Foo {
>   func bar() {}
>   func baz() {}
> }
> 
> After this conversion, bar and baz are in the same lexical scope. No new 
> definitions of anything are required.

Sure, but this does effectively violate lexical scope boundaries as they exist 
in the original source.

> 
> You can also think of the “Foo_Private.h” headers that can be shared amongst 
> several different files in Objective-C.
> 
> Charles
> 

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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Ben Rimmington via swift-evolution]

> On 22 Mar 2017, at 17:41, Itai Ferber wrote:
> 
> What’s the use case that you were thinking of? KeyPaths could be useful in 
> the case where you don’t need to customize your key names, but cannot 
> represent a custom case like
> 
> public struct Post {
> var authorID: Int
> var bodyText: String
> 
> private enum CodingKeys : String, CodingKey {
> case authorID = "author_id"
> case bodyText = "body_text"
> }
> }
> Or am I misunderstanding?
> 

For custom names, the `CodingKeys` enum does seem like the best design, unless 
an attribute can be used.

public struct Post : Codable {
@codable(name: "author_id") var authorID: Int
@codable(name: "body_text") var bodyText: String
}

If each `KeyPath` encapsulates the type information, the `decode` methods won't 
need a `type` parameter.

/// Primitive decoding methods (for single-value and keyed containers).
open class DecodingContainer {
open func decode(for keyPath: KeyPath)   throws -> Bool
open func decode(for keyPath: KeyPath)throws -> Int
open func decode(for keyPath: KeyPath)   throws -> UInt
open func decode(for keyPath: KeyPath)  throws -> Float
open func decode(for keyPath: KeyPath) throws -> 
Double
open func decode(for keyPath: KeyPath) throws -> 
String
open func decode(for keyPath: KeyPath)   throws -> Data
}

/// Keyed containers inherit the primitive decoding methods.
open class KeyedDecodingContainer : DecodingContainer {
open func decode(for keyPath: KeyPath) throws -> Value
}

-- Ben

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

Re: [swift-evolution] Pitch: Partial Implementations

[Charles Srstka via swift-evolution]

> On Mar 23, 2017, at 2:15 PM, Matthew Johnson  wrote:
> 
> What I’m suggesting is that we could accomplish the same functionality by 
> enhancing extensions.  You can make a case that using a different keyword for 
> same-module extensions that are allowed to have stored properties is a good 
> idea.  I’m not sure I would support that though.

The problem is that people are using extensions to implement part of the 
original class definition. Part of what is making that pattern awkward is that 
private members are not accessible from the extensions. Given the SE-0159 
discussion, it appears that there is a non-negligible threat of losing the very 
ability to have scoped members at all if we don’t think of a better alternate 
solution.

>> 2) I’m not proposing changing the meaning of ‘private’ here. Since partial 
>> implementations would all glom into one lexical scope, all the current 
>> access control rules would apply as they currently do. This is simply a way 
>> to write a class or struct declaration in multiple parts, without having to 
>> use extensions.
> 
> This does not fit with any definition of “lexical scope” I am familiar with.  
> I wouldn’t want to see Swift adopt this definition of lexical scope.

No definitions required. All I’m proposing is basically preprocessing the thing 
into one type declaration.

class Foo {
func bar() {}
}

partial Foo {
func baz() {}
}

just becomes syntactic sugar for:

class Foo {
func bar() {}
func baz() {}
}

After this conversion, bar and baz are in the same lexical scope. No new 
definitions of anything are required.

You can also think of the “Foo_Private.h” headers that can be shared amongst 
several different files in Objective-C.

Charles

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> On 23 Mar 2017, at 16:49, Drew Crawford  > wrote:
> 
>> 
>> 
>> 
>> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com 
>> ) wrote:
>> 
>>> > We will get static linking at some point in the near future.
>> 
>> Static linking does not fix this issue. Just change "framework" to ".a".
>> 
> I'm curious to hear what issue your client had with you using many frameworks 
> that static linking doesn't solve.
> 
>>> > If we wait until we get submodules, we won't be able to revisit. This is 
>>> > probably our last chance to "remove" a feature. Submodules can always add 
>>> > features down the way.
>> 
>> Maybe submodules will solve this issue, maybe not.  But submodules are 
>> *much* more complex than scoped access:
>> 
>> * Performance.  This is hot code we compile with WMO.  Moving it into a 
>> submodule could reduce visibility for optimization in a way that causes a 
>> performance regression.  In particular, we know that specialization of T is 
>> a performance requirement, it isn't clear whether that would be preserved.  
>> Does WMO provide the same visibility across submodules?  Nobody knows.
>> 
> I don't see why submodules could not profit from WMO: the module is still 
> compiled all together. Submodules are simply a scoping/hiding mechanism.
>> * Namespacing.  It's possible that one program may ship 3-4 versions of this 
>> code because each dependency has a slightly different version under our 
>> current samizdat process.  It is not clear whether submodules would avoid 
>> the "duplicate symbols" issue from C/ObjC.  Xiaodi seems quite concerned 
>> about a related "duplicate functions" problem involved with private today, 
>> doubling down on that is not a good idea.
>> 
> That looks like a very corner case. I haven't yet found myself in the case 
> where I needed multiple versions of a code base in a same product (binary, 
> framework, application)
>> * It is not clear whether submodules are from an objectcode point of view 
>> merged into the parent library or kept as individual libraries
>> 
> It would be very strange to me if they were independent libraries: what would 
> different them from modules then? No other language I've used works that way.
>> * It is not clear from a .swiftmodule point of view whether submodules are 
>> merged into the parent module or distributed as .swiftmodules / .swiftdocs
>> 
>> * Not clear how much ABI impact there is from submodules at a time when we 
>> are supposed to be trying to stabilize it
>> 
>> I would love to believe that a proposal on submodules will come through 
>> having solutions to all these issues and many more, then we will implement 
>> it and all sing kumbayah.  But we are a long distance from that, and it may 
>> never happen at all, certainly we cannot evaluate proposals that haven't 
>> been written.  Meanwhile we have a solution in the hand.
>> 
> But at the same time, we can't write and review proposals with no regard for 
> future proposals coming down the road or we end up with a clunky language.

Or we can just wait until access control and / or submodules are part of a 
release theme and address these issues more holistically.  As I have said 
before, the details of the submodule design we eventually end up with could 
influence what problems people want access control to address (or not address). 
 It’s possible that we could end up with a design that allows us to eliminate 
`fileprivate` instead of `private` if we feel we must eliminate one of them.  
Right now we just don’t know enough to say for sure.

> ___
> 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

Re: [swift-evolution] Pitch: Partial Implementations

[Matthew Johnson via swift-evolution]

> On Mar 23, 2017, at 2:04 PM, Charles Srstka  wrote:
> 
>> On Mar 23, 2017, at 1:21 PM, Matthew Johnson > > wrote:
>> 
>> If we wanted to allow code like this to be written we wouldn’t need a new 
>> keyword to do it.  You are proposing two things here:
>> 
>> 1) Allow stored properties in same-module extensions.  This has been 
>> discussed in the past and is a possibility, but I suspect it is not in scope 
>> for consideration during Swift 4.
>> 2) Change the meaning of `private` to not mean lexical scope anymore, but 
>> instead be lexical scope or an extension of the type introducing the lexical 
>> scope in the same module.  Changes to access control other than the proposal 
>> currently under review are out of scope for Swift 4.
> 
> Neither, actually:
> 
> 1) I’m proposing we no longer encourage extensions at all for this purpose. 
> My proposal is simply to allow breaking up declarations into parts, instead.

What I’m suggesting is that we could accomplish the same functionality by 
enhancing extensions.  You can make a case that using a different keyword for 
same-module extensions that are allowed to have stored properties is a good 
idea.  I’m not sure I would support that though.

> 
> 2) I’m not proposing changing the meaning of ‘private’ here. Since partial 
> implementations would all glom into one lexical scope, all the current access 
> control rules would apply as they currently do. This is simply a way to write 
> a class or struct declaration in multiple parts, without having to use 
> extensions.

This does not fit with any definition of “lexical scope” I am familiar with.  I 
wouldn’t want to see Swift adopt this definition of lexical scope.

> 
> Charles
> 

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

Re: [swift-evolution] Pitch: Partial Implementations

[Charles Srstka via swift-evolution]

> On Mar 23, 2017, at 1:21 PM, Matthew Johnson  wrote:
> 
> If we wanted to allow code like this to be written we wouldn’t need a new 
> keyword to do it.  You are proposing two things here:
> 
> 1) Allow stored properties in same-module extensions.  This has been 
> discussed in the past and is a possibility, but I suspect it is not in scope 
> for consideration during Swift 4.
> 2) Change the meaning of `private` to not mean lexical scope anymore, but 
> instead be lexical scope or an extension of the type introducing the lexical 
> scope in the same module.  Changes to access control other than the proposal 
> currently under review are out of scope for Swift 4.

Neither, actually:

1) I’m proposing we no longer encourage extensions at all for this purpose. My 
proposal is simply to allow breaking up declarations into parts, instead.

2) I’m not proposing changing the meaning of ‘private’ here. Since partial 
implementations would all glom into one lexical scope, all the current access 
control rules would apply as they currently do. This is simply a way to write a 
class or struct declaration in multiple parts, without having to use extensions.

Charles

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[David Hart via swift-evolution]

> On 23 Mar 2017, at 16:49, Drew Crawford  wrote:
> 
> 
> 
> 
>> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote:
>> 
>> > We will get static linking at some point in the near future.
> 
> Static linking does not fix this issue. Just change "framework" to ".a".
> 
I'm curious to hear what issue your client had with you using many frameworks 
that static linking doesn't solve.

>> > If we wait until we get submodules, we won't be able to revisit. This is 
>> > probably our last chance to "remove" a feature. Submodules can always add 
>> > features down the way.
> 
> Maybe submodules will solve this issue, maybe not.  But submodules are *much* 
> more complex than scoped access:
> 
> * Performance.  This is hot code we compile with WMO.  Moving it into a 
> submodule could reduce visibility for optimization in a way that causes a 
> performance regression.  In particular, we know that specialization of T is a 
> performance requirement, it isn't clear whether that would be preserved.  
> Does WMO provide the same visibility across submodules?  Nobody knows.
> 
I don't see why submodules could not profit from WMO: the module is still 
compiled all together. Submodules are simply a scoping/hiding mechanism.
> * Namespacing.  It's possible that one program may ship 3-4 versions of this 
> code because each dependency has a slightly different version under our 
> current samizdat process.  It is not clear whether submodules would avoid the 
> "duplicate symbols" issue from C/ObjC.  Xiaodi seems quite concerned about a 
> related "duplicate functions" problem involved with private today, doubling 
> down on that is not a good idea.
> 
That looks like a very corner case. I haven't yet found myself in the case 
where I needed multiple versions of a code base in a same product (binary, 
framework, application)
> * It is not clear whether submodules are from an objectcode point of view 
> merged into the parent library or kept as individual libraries
> 
It would be very strange to me if they were independent libraries: what would 
different them from modules then? No other language I've used works that way.
> * It is not clear from a .swiftmodule point of view whether submodules are 
> merged into the parent module or distributed as .swiftmodules / .swiftdocs
> 
> * Not clear how much ABI impact there is from submodules at a time when we 
> are supposed to be trying to stabilize it
> 
> I would love to believe that a proposal on submodules will come through 
> having solutions to all these issues and many more, then we will implement it 
> and all sing kumbayah.  But we are a long distance from that, and it may 
> never happen at all, certainly we cannot evaluate proposals that haven't been 
> written.  Meanwhile we have a solution in the hand.
> 
But at the same time, we can't write and review proposals with no regard for 
future proposals coming down the road or we end up with a clunky language.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Michel Fortin via swift-evolution]

> Le 23 mars 2017 à 12:03, Matthew Johnson via swift-evolution 
>  a écrit :
> 
> I think it’s likely that a non-trivial degree of any confusion is related to 
> the mistake we made in choosing the names.  Both `fileprivate` and `private` 
> include the word `private` in their name.  If we had left `private` alone and 
> introduces scoped access with the name `scoped` I think the difference would 
> have been much more clear to most people who have been confused.

An interesting question when digging into the past is: would the core team have 
accepted the "scoped" proposal knowing what we know today? It's hard to judge 
form the outside how much the acceptance of scoped-private by the core team at 
that time was linked to it being able to replace most instances of 
file-private, but I'm under the impression that it was the tipping point.

The current proposal, as written, is to return to the Swift 2 model, making it 
as if the initial `scoped` proposal for Swift 3 had been rejected. Which brings 
another interesting question: let's assume for a moment that this proposal to 
revert to the Swift 2 model is accepted as is... should we also backtrack on 
the idea of allowing `public` members inside of `private` classes? As I 
remember, this was added to Swift 3 to make it possible to have `fileprivate` 
members inside of `private` types. This proposal leaves this unchanged though, 
which means it's not a complete revert to the Swift 2 model. Is this an 
oversight? Maybe it'd break source compatibility a bit too much.

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Tony Parker via swift-evolution]

Hi Oliver,

> On Mar 23, 2017, at 7:55 AM, Oliver Jones via swift-evolution 
>  wrote:
> 
> Like everyone I’m excited by this new proposal.  But…
> 
> > protocol Codable: Adopted by types to opt into archival. Conformance may be 
> > automatically derived in cases where all properties are also Codable.
> 
> … can I make one suggestion.  Please do not repeat the mistakes of NSCoding 
> in combining the encoding and decoding into a single protocol.  Just as there 
> are Encoder and Decoder classes their should be Encodable and Decodable 
> protocols (maybe have an aggregate Codable protocol for convenience but do 
> not force it).
> 
> My reasoning:
> 
> Sometimes you only want to decode or encode and object and not vice versa.  
> This is often the case with Web APIs and JSON serialisation.  
> 
> Eg:
> 
> Often an app only consumes (decodes) JSON encoded objects and never writes 
> them out (a read only app for example). So the encode(to:) methods are 
> completely redundant and someone adopting Codable should not be forced to 
> write them.  
> 
> If only I had a dollar for all the times I’ve seen this sort of code in 
> projects:
> 
> class MyClass : NSCoding {
> init?(coder: NSCoder) {
>   // ... some decoding code
> }
> 
> func encode(with aCoder: NSCoder) {
>preconditionFailure(“Not implemented”)
> }
> }
> 
> 
> Another example: 
> 
> Web APIs often take data in a different structure as input (i.e. “Request” 
> objects) than they output.  These request objects are only ever encoded and 
> never decoded by an application so implementing init(from:) is completely 
> redundant.
> 
> Personally I think the approach taken by libraries like Wrap 
> (https://github.com/johnsundell/wrap ) 
> and Unbox (https://github.com/JohnSundell/Unbox 
> ) is a much better design.  Encoding 
> and decoding should not be the same protocol.
> 
> Yes I understand that Codable could provide no-op (or preconditionFailure) 
> protocol extension based default implementations of init(from:) and 
> encode(to:) (or try to magic up implementations based on the Codable nature 
> of public properties as suggested in the proposal) but to me that seems like 
> a hack that is papering over bad design.  I think this joint Codable design 
> probably fails the Liskov substitution principle too.
> 
> So I again implore you to consider splitting Codable into two protocols, one 
> for encoding and another for decoding.
> 
> Sorry if I’m repeating what other people have already said.  I’ve not read 
> every response to this proposal on the list.
> 
> Regards

Thanks for your feedback. We are indeed considering splitting this up into 3 
protocols instead of 1 (“Encodable", “Decodable", "Codable : Encodable, 
Decodable”).

The main counterpoint is the additional complexity inherent in this approach. 
We are considering if the tradeoff is worth it.

- Tony


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

Re: [swift-evolution] Pitch: Partial Implementations

[Rien via swift-evolution]

I think the access levels should be revised, no need to introduce a new concept.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 23 Mar 2017, at 19:12, Charles Srstka via swift-evolution 
>  wrote:
> 
> MOTIVATION:
> 
> In current Swift, a pattern has emerged among some developers, in order to 
> logically group parts of a class or struct’s declaration, particularly around 
> protocols:
> 
> class Foo {
>   …
> }
> 
> extension Foo: SomeProtocol {
>   ...
> }
> 
> extension Foo: SomeOtherProtocol {
>   ...
> }
> 
> This has certain appealing characteristics; in addition to the obvious 
> organizational property, this pattern also keeps protocol implementations 
> close to the declaration of conformance to the protocol. Unfortunately, there 
> are a couple of problems:
> 
> 1. Extensions cannot contain stored properties. This means that if a protocol 
> requires a property, and it makes sense for that property to be stored, its 
> conformance cannot be completely contained within the extension, but rather 
> some of it must be in the main declaration.
> 
> 2. It’s not uncommon for these protocol conformances to need access to the 
> type’s private internal state, but extensions do not have access to private 
> members within the state. This necessitates declaring the needed state as 
> fileprivate rather than private, a fact has been a primary rallying point in 
> the battle that’s currently raging on this mailing list over whether we 
> should keep the ‘private’ access modifier, and which I would surmise is 
> probably the major remaining use of ‘fileprivate’ in modern Swift code.
> 
> 3. Since members that are declared ‘fileprivate’ cannot be accessed outside 
> the file, these protocol conformance extensions must belong to the same file 
> as the original declaration, which can lead to very long file sizes when the 
> code to implement a protocol is very long, or when a type supports a large 
> number of protocols.
> 
> PROPOSED SOLUTION:
> 
> Add a keyword to declare only part of a type’s implementation. I am 
> suggesting ‘partial’ as the keyword, but this can be changed for a better 
> name if needed. Partial conformances would be declared like this:
> 
> class Foo {
>   private func somePrivateMethod() { … }
> }
> 
> partial Foo: SomeProtocol {
>   var someRequiredProperty: Int = 5
> 
>   func someRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> partial Foo: SomeOtherProtocol {
>   func someOtherRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> When compiling this, the compiler would simply treat all the contents of 
> partial declarations as if they were located within the original declaration, 
> making the above equivalent to this:
> 
> class Foo: SomeProtocol, SomeOtherProtocol {
>   private func somePrivateMethod() { … }
> 
>   var someRequiredProperty: Int = 5
> 
>   func someRequiredMethod() {
>   self.somePrivateMethod()
>   }
> 
>   func someOtherRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> Obviously, partial declarations would only be allowed within the same module 
> (or submodule, once we get them) as the original declaration.
> 
> The advantages to this approach are:
> 
> 1. Given a pattern that many developers are adopting, this proposal would 
> provide a mechanism to follow that pattern properly instead of repurposing a 
> mechanism—extensions—which was intended for something else. The Swift manual 
> claims that extensions are meant to add things “to a type that is declared 
> elsewhere, or even to a type that you imported from a library or a 
> framework,” not for separating your own code into parts.
> 
> 2. Partial implementations can now implement the entirety of a protocol, 
> including stored properties if the protocol necessitates them.
> 
> 3. Since the contents of all partial implementations are considered to be 
> part of the same declaration, the contents of partial implementations can 
> access private members, which should allow the almost complete elimination of 
> ‘fileprivate’ from developers’ codebases, simplifying the access control 
> model.
> 
> 4. Since partial implementations are not dependent on file-based 
> organization, they can be stored in separate files, as long as those files 
> are compiled into the same module, thus allowing for smaller, leaner, source 
> files that are easier to read and understand.
> 
> What do you think?
> 
> Charles
> 
> ___
> 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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 21 Mar 2017, at 08:05, Rien  wrote:
> 
> +1

-1: I have revised my opinion.


> 
>>  • What is your evaluation of the proposal?
> 
> Makes the language easier to understand, lowers cognitive load during coding.
> I also hope this will pave the way for a overhaul of the access level system 
> including modularization.

I still hope that fileprivate will be dumped one day. Presumably when a better 
proposal is on the table.
However it is clear that for some people the disadvantage of dropping it now is 
bigger than the advantage to the proponents together.
Regardless of wether the need is only perceived or not.

> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> yes.

yes, but not without an alternative solution in place at the time fileprivate 
is dropped.


> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> Yes

Yes

> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> private vs fileprivate seems swift-only, as such I have no comparison.

Same

> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Followed and participated in the discussions.


Same.

> 
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>> through March 27, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  • What is your evaluation of the proposal?
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  • Does this proposal fit well with the feel and direction of Swift?
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> 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

Re: [swift-evolution] Pitch: Partial Implementations

[Matthew Johnson via swift-evolution]

> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> MOTIVATION:
> 
> In current Swift, a pattern has emerged among some developers, in order to 
> logically group parts of a class or struct’s declaration, particularly around 
> protocols:
> 
> class Foo {
>   …
> }
> 
> extension Foo: SomeProtocol {
>   ...
> }
> 
> extension Foo: SomeOtherProtocol {
>   ...
> }
> 
> This has certain appealing characteristics; in addition to the obvious 
> organizational property, this pattern also keeps protocol implementations 
> close to the declaration of conformance to the protocol. Unfortunately, there 
> are a couple of problems:
> 
> 1. Extensions cannot contain stored properties. This means that if a protocol 
> requires a property, and it makes sense for that property to be stored, its 
> conformance cannot be completely contained within the extension, but rather 
> some of it must be in the main declaration.
> 
> 2. It’s not uncommon for these protocol conformances to need access to the 
> type’s private internal state, but extensions do not have access to private 
> members within the state. This necessitates declaring the needed state as 
> fileprivate rather than private, a fact has been a primary rallying point in 
> the battle that’s currently raging on this mailing list over whether we 
> should keep the ‘private’ access modifier, and which I would surmise is 
> probably the major remaining use of ‘fileprivate’ in modern Swift code.
> 
> 3. Since members that are declared ‘fileprivate’ cannot be accessed outside 
> the file, these protocol conformance extensions must belong to the same file 
> as the original declaration, which can lead to very long file sizes when the 
> code to implement a protocol is very long, or when a type supports a large 
> number of protocols.
> 
> PROPOSED SOLUTION:
> 
> Add a keyword to declare only part of a type’s implementation. I am 
> suggesting ‘partial’ as the keyword, but this can be changed for a better 
> name if needed. Partial conformances would be declared like this:
> 
> class Foo {
>   private func somePrivateMethod() { … }
> }
> 
> partial Foo: SomeProtocol {
>   var someRequiredProperty: Int = 5
> 
>   func someRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> partial Foo: SomeOtherProtocol {
>   func someOtherRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> When compiling this, the compiler would simply treat all the contents of 
> partial declarations as if they were located within the original declaration, 
> making the above equivalent to this:
> 
> class Foo: SomeProtocol, SomeOtherProtocol {
>   private func somePrivateMethod() { … }
> 
>   var someRequiredProperty: Int = 5
> 
>   func someRequiredMethod() {
>   self.somePrivateMethod()
>   }
> 
>   func someOtherRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> Obviously, partial declarations would only be allowed within the same module 
> (or submodule, once we get them) as the original declaration.
> 
> The advantages to this approach are:
> 
> 1. Given a pattern that many developers are adopting, this proposal would 
> provide a mechanism to follow that pattern properly instead of repurposing a 
> mechanism—extensions—which was intended for something else. The Swift manual 
> claims that extensions are meant to add things “to a type that is declared 
> elsewhere, or even to a type that you imported from a library or a 
> framework,” not for separating your own code into parts.
> 
> 2. Partial implementations can now implement the entirety of a protocol, 
> including stored properties if the protocol necessitates them.
> 
> 3. Since the contents of all partial implementations are considered to be 
> part of the same declaration, the contents of partial implementations can 
> access private members, which should allow the almost complete elimination of 
> ‘fileprivate’ from developers’ codebases, simplifying the access control 
> model.
> 
> 4. Since partial implementations are not dependent on file-based 
> organization, they can be stored in separate files, as long as those files 
> are compiled into the same module, thus allowing for smaller, leaner, source 
> files that are easier to read and understand.
> 
> What do you think?

If we wanted to allow code like this to be written we wouldn’t need a new 
keyword to do it.  You are proposing two things here:

1) Allow stored properties in same-module extensions.  This has been discussed 
in the past and is a possibility, but I suspect it is not in scope for 
consideration during Swift 4.
2) Change the meaning of `private` to not mean lexical scope anymore, but 
instead be lexical scope or an extension of the type introducing the lexical 
scope in the same module.  Changes to access control other than the proposal 
currently under review are out of 

[swift-evolution] Pitch: Partial Implementations

[Charles Srstka via swift-evolution]

MOTIVATION:

In current Swift, a pattern has emerged among some developers, in order to 
logically group parts of a class or struct’s declaration, particularly around 
protocols:

class Foo {
…
}

extension Foo: SomeProtocol {
...
}

extension Foo: SomeOtherProtocol {
...
}

This has certain appealing characteristics; in addition to the obvious 
organizational property, this pattern also keeps protocol implementations close 
to the declaration of conformance to the protocol. Unfortunately, there are a 
couple of problems:

1. Extensions cannot contain stored properties. This means that if a protocol 
requires a property, and it makes sense for that property to be stored, its 
conformance cannot be completely contained within the extension, but rather 
some of it must be in the main declaration.

2. It’s not uncommon for these protocol conformances to need access to the 
type’s private internal state, but extensions do not have access to private 
members within the state. This necessitates declaring the needed state as 
fileprivate rather than private, a fact has been a primary rallying point in 
the battle that’s currently raging on this mailing list over whether we should 
keep the ‘private’ access modifier, and which I would surmise is probably the 
major remaining use of ‘fileprivate’ in modern Swift code.

3. Since members that are declared ‘fileprivate’ cannot be accessed outside the 
file, these protocol conformance extensions must belong to the same file as the 
original declaration, which can lead to very long file sizes when the code to 
implement a protocol is very long, or when a type supports a large number of 
protocols.

PROPOSED SOLUTION:

Add a keyword to declare only part of a type’s implementation. I am suggesting 
‘partial’ as the keyword, but this can be changed for a better name if needed. 
Partial conformances would be declared like this:

class Foo {
private func somePrivateMethod() { … }
}

partial Foo: SomeProtocol {
var someRequiredProperty: Int = 5

func someRequiredMethod() {
self.somePrivateMethod()
}
}

partial Foo: SomeOtherProtocol {
func someOtherRequiredMethod() {
self.somePrivateMethod()
}
}

When compiling this, the compiler would simply treat all the contents of 
partial declarations as if they were located within the original declaration, 
making the above equivalent to this:

class Foo: SomeProtocol, SomeOtherProtocol {
private func somePrivateMethod() { … }

var someRequiredProperty: Int = 5

func someRequiredMethod() {
self.somePrivateMethod()
}

func someOtherRequiredMethod() {
self.somePrivateMethod()
}
}

Obviously, partial declarations would only be allowed within the same module 
(or submodule, once we get them) as the original declaration.

The advantages to this approach are:

1. Given a pattern that many developers are adopting, this proposal would 
provide a mechanism to follow that pattern properly instead of repurposing a 
mechanism—extensions—which was intended for something else. The Swift manual 
claims that extensions are meant to add things “to a type that is declared 
elsewhere, or even to a type that you imported from a library or a framework,” 
not for separating your own code into parts.

2. Partial implementations can now implement the entirety of a protocol, 
including stored properties if the protocol necessitates them.

3. Since the contents of all partial implementations are considered to be part 
of the same declaration, the contents of partial implementations can access 
private members, which should allow the almost complete elimination of 
‘fileprivate’ from developers’ codebases, simplifying the access control model.

4. Since partial implementations are not dependent on file-based organization, 
they can be stored in separate files, as long as those files are compiled into 
the same module, thus allowing for smaller, leaner, source files that are 
easier to read and understand.

What do you think?

Charles

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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Mar 23, 2017, at 9:03 AM, Charlie Monroe  wrote:
> 
>> 
>> On Mar 23, 2017, at 9:44 AM, Slava Pestov > > wrote:
>> 
>>> 
>>> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution 
>>> > wrote:
>>> 
 
 On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution 
 > wrote:
 
 
> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution 
> > wrote:
> 
> 
>> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution 
>> > wrote:
>> * What is your evaluation of the proposal?
> 
> In favour.
> 
> Like others I can foresee there being a bit of pain for some developers, 
> but I think it's worth it to be more explicit about what's going on, and 
> to clean up a feature that's just for supporting a specific other 
> language.
> 
> My main concern is on whether things could be made a bit easier; 
> specifically I wonder whether we could introduce an option (to the 
> compiler?) to trigger warnings anywhere there is a possible missing @objc 
> attribute. Basically on any code that produces bridging headers this 
> would give a warning anywhere that @objc would have been inferred in the 
> past, but will no longer be. Of course this will generate a lot of 
> warnings, but it'll be an easier way for developers to go through and 
> make sure they didn't miss something. Xcode could offer this 
> automatically during migration, and the developer can turn it off when 
> they're done. Not perfect, but it may be a little extra help for those 
> most affected?
 
 The source compatibility section of the proposal
 

 https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
  
 
 
 describes the use of NS_DEPRECATED in the generated header for Swift 3 
 compatibility mode to get warnings on uses of entities that are implicitly 
 @objc but will no longer be in Swift 4. Does that address your concern?
 
 I’ve also heard the idea of putting the same warnings into the generated 
 Objective-C thunks by NSLog’ing the same information as an opt-in, 
 pre-Swift-4-migration step to help catch the tricky cases where an 
 Objective-C entrypoint is getting called.
>>> 
>>> I would very much like that, mostly for catching all scenarios with 
>>> bindings on the Mac.
>>> 
>>> Otherwise, I agree with the proposal, just am a bit concerned with some of 
>>> my apps that heavily use bindings…
>> 
>> Perhaps a better solution than NSLog would be if the existing code coverage 
>> support could be modified to instrument @objc thunks, but I don’t know the 
>> details well enough to say if this would be practical to implement in the 
>> Swift 4 time frame.
> 
> What about a symbol for a breakpoint? Like Auto Layout and many other 
> frameworks (e.g. break on _NSErrorLog(), etc.) have…

That’s a great idea! We could have the implicit @objc thunks call into 
_swift3ImplicitObjCEntrypoint (or similar).

- Doug


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

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

[Philippe Hausler via swift-evolution]

> On Mar 23, 2017, at 10:14 AM, Jordan Rose  wrote:
> 
>> 
>> On Mar 23, 2017, at 09:05, Joe Groff via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution 
 > wrote:
 
 Alternatives considered
 
 Do nothing and continue to accept this implicit conversion.
>>> 
>>> One alternative would be to import CFArray as a typealias for NSArray, etc, 
>>> erasing the distinction between the two types completely. I did suggest 
>>> this to Jordan at one point and he pointed out some problems, but I don’t 
>>> remember them now. Hopefully Jordan can chime in.
>> 
>> I'd prefer this solution as well, especially since toll-free bridged CF 
>> types are nearly indistinguishable from their NS counterparts at runtime, so 
>> trying to maintain the distinction for dynamic casts or reflection has 
>> historically been problematic. Part of the problem is that, as Charlie 
>> noted, CFArray/Dictionary/Set can take an arbitrary set of retain/release 
>> callbacks, in which case the resulting container isn't fully 
>> NSArray-compatible. I'm not sure that happens often enough with CF 
>> containers in the SDKs that accounting for that case is worth the burden of 
>> separating the types.
> 
> [adding Philippe, who has also thought about this problem]
> 
> The abstract problems I know of are:
> 
> (1) custom callbacks
> (2) it's legal to import CF without importing Foundation
> (3) CF types will not get generics
> 
> In practice, (1) is both exceedingly rare (only one public API that I know 
> of) and something that can be worked around by using the CF APIs on the 
> array—that is, we can keep CFArrayGetValueAtIndex around and just have it 
> take an NSArray. (2) is something we can deprecate and/or fix. (3) just means 
> we have to import the CFArray as NSArray rather than Array.
> 
> We would have to be very sure that all toll-free bridged CF types are marked 
> as such; adding toll-free bridging would not be a backwards-compatible change 
> since it would conflate two types into one. This leads us to a fourth 
> problem: this is a source-breaking change if anyone has overloads for both 
> CFArray and NSArray, or adds a protocol to CFArray that NSArray already has. 
> We probably already need to solve the latter in some way, and could try to 
> cross our fingers about the former.
> 
> Jordan


I think there are a bit more ramifications that are under the hood here; we 
should consider the full extent of what changing the behavior between CF types 
and NS types a bit more deeply than just a cursory proposal. Additionally as 
with any change to Foundation and CoreFoundation this should be passed around 
internally to the appropriate stakeholders that will be in charge of providing 
long term support for any sort of change this would apply to.

As an initial gut reaction; I would say that this is well past our stage for 
changes for Foundation and I would hate to see something be pushed out last 
minute that takes away development time from other important tasks on the table.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

[Charles Srstka via swift-evolution]

I didn’t even know the compiler still supported these implicit conversions. So, 
+1, I guess.

Charles

> On Mar 23, 2017, at 12:35 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Good evening all,
> 
> Attached is the proposal text that came out of a short discussion on Twitter 
>  about squashing one 
> more case of implicit conversions in the language.  This proposal seeks to 
> remove the implicit nature of toll-free bridging in favor of an explicit 
> as-cast.  The proposal can also be read as a gist 
> , and the 
> most up-to-date copy may be found on swift-evolution itself 
> .
> 
> Cheers,
> 
> ~Robert Widmann
> 
> Explicit Toll-Free Conversions
> 
> Proposal: SE- 
> Authors: Robert Widmann 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> To continue removing further implicit conversions from the language, implicit 
> toll-free bridging should be deprecated in Swift 3 and removed in Swift 4.0.
> 
>  
> Motivation
> 
> Swift currently allows implicit conversions between CF types and their 
> toll-free-bridged Objective-C counterparts. This was meant to maintain parity 
> with the feature in Objective-C. However, the presence of implicit 
> conversions is no longer in-line with the expectations of Swift's type 
> system. In addition, advancements in the Clang importer have made interaction 
> with imported CF and Foundation types nearly seamless - obviating the need 
> for this feature in general. For the sake of safety, and in the spirit of 
> continuing the work of SE-0072 
> 
>  and facilitating SE-0083 
> ,
>  we propose the deprecation and removal of this implicit conversion in favor 
> of an explicit as cast.
> 
>  
> Proposed
>  solution
> 
> The implicit conversion between toll-free-bridged types shall be removed. In 
> its place, the user should use explicit ascasts to convert bewteen bridged CF 
> and Objective-C types.
> 
>  
> Detailed
>  Design
> 
> When in Swift 3 mode, the compiler shall warn when it encounters the need to 
> perform an implicit conversion. At the warning site, it can offer the 
> explicit as cast to the user as a fix-it.
> 
> func nsToCF(_ ns: NSString) -> CFString {  
>   return ns // warning: 'NSString' is not implicitly convertible to 
> 'CFString'; did you mean to use 'as' to explicitly convert?
> }
> 
> func cfToNS(_ cf: CFString) -> NSString { 
>   return cf // warning: 'CFString' is not implicitly convertible to 
> 'NSString'; did you mean to use 'as' to explicitly convert?
> }
> When in Swift 4 mode, the compiler shall no longer perform the implicit 
> conversion and relying on this behavior will be a hard error.
> 
> func nsToCF(_ ns: NSString) -> CFString {  
>   return ns // error: cannot convert return expression of type 'NSString' to 
> return type 'CFString'
> }
> 
> func cfToNS(_ cf: CFString) -> NSString { 
>   return cf // error: cannot convert return expression of type 'CFString' to 
> return type 'NSString'
> }
>  
> Source
>  compatibility
> 
> This introduces a source-breaking change that affects consumers of APIs that 
> are explicitly taking or vending instances of bridged CF or Objective-C 
> types. However, recent importer advances have made APIs like this far less 
> numerous. In practice, we expect the source breakage to eludicate places 
> where implicit conversions were accidentally being performed behind the 
> user's back.
> 
>  
> Effect
>  on ABI stability
> 
> This proposal has no effect on the Swift ABI.
> 
>  
> Effect
>  on API resilience
> 
> This proposal has no effect on API resilience.
> 
>  
> Alternatives
>  considered
> 
> Do nothing and continue to accept this implicit conversion.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Brent Royal-Gordon via swift-evolution]

To what extent could your need for safety be satisfied by (a) giving the 
property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a 
very small unit test/shell script/Perl script which makes sure references to 
that very unique name only appear between the two "MARK:" comments?

-- 
Brent Royal-Gordon
Sent from my iPhone

> On Mar 23, 2017, at 10:11 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> I can't go into detail in public, but I can say that we did a postmortem on 
>> a large lost sale and the customer specifically cited the number of 
>> frameworks in our product as an integration barrier for them.  Most iOS SDKs 
>> are distributed as a single framework and so with that backdrop the friction 
>> makes more sense.
>> 
>> As a result of that I have about 5 bugs open on how to reduce our framework 
>> footprint so our tools are easier for our users to integrate.  There are a 
>> variety of solutions we use on that, what you see here is one of the saner 
>> ones, believe it or not.
>> 
>> Whether or not the technical requirement makes sense to you, the business 
>> case is very clear.  So clear that if scoped were removed we would almost 
>> certainly keep the file and its potential threading bugs, over promoting a 
>> new framework.  Sales >> code, unfortunately.
>> 
> Oh, come on — that sounds like removing new private would threaten your 
> existence… in this case, afaics a simple search & replace (private -> 
> fileprivate) works just fine.
> You may not like that solution, but others might not even notice the 
> difference. 
> Imho the importance of SE-25 has been exaggerated tremendously before it was 
> added, and the same seems to happen now, when its removal is discussed.
> 
> We shouldn't overdramatise this question, and don't invent arguments to 
> support partialities:
> Access control worked fine in Swift 2, and fileprivate didn't increase the 
> complexity of the language in a way that makes it impossible to teach it.
> 
> There are arguments for both positions, and they are valid — but there is a 
> huge variance in the perceived importance, and discussion has only very 
> limited effect on this.
> ___
> 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

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

[Jordan Rose via swift-evolution]

> On Mar 23, 2017, at 09:05, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
>>> Alternatives considered
>>> 
>>> Do nothing and continue to accept this implicit conversion.
>> 
>> One alternative would be to import CFArray as a typealias for NSArray, etc, 
>> erasing the distinction between the two types completely. I did suggest this 
>> to Jordan at one point and he pointed out some problems, but I don’t 
>> remember them now. Hopefully Jordan can chime in.
> 
> I'd prefer this solution as well, especially since toll-free bridged CF types 
> are nearly indistinguishable from their NS counterparts at runtime, so trying 
> to maintain the distinction for dynamic casts or reflection has historically 
> been problematic. Part of the problem is that, as Charlie noted, 
> CFArray/Dictionary/Set can take an arbitrary set of retain/release callbacks, 
> in which case the resulting container isn't fully NSArray-compatible. I'm not 
> sure that happens often enough with CF containers in the SDKs that accounting 
> for that case is worth the burden of separating the types.

[adding Philippe, who has also thought about this problem]

The abstract problems I know of are:

(1) custom callbacks
(2) it's legal to import CF without importing Foundation
(3) CF types will not get generics

In practice, (1) is both exceedingly rare (only one public API that I know of) 
and something that can be worked around by using the CF APIs on the array—that 
is, we can keep CFArrayGetValueAtIndex around and just have it take an NSArray. 
(2) is something we can deprecate and/or fix. (3) just means we have to import 
the CFArray as NSArray rather than Array.

We would have to be very sure that all toll-free bridged CF types are marked as 
such; adding toll-free bridging would not be a backwards-compatible change 
since it would conflate two types into one. This leads us to a fourth problem: 
this is a source-breaking change if anyone has overloads for both CFArray and 
NSArray, or adds a protocol to CFArray that NSArray already has. We probably 
already need to solve the latter in some way, and could try to cross our 
fingers about the former.

Jordan

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Tino Heth via swift-evolution]

> I can't go into detail in public, but I can say that we did a postmortem on a 
> large lost sale and the customer specifically cited the number of frameworks 
> in our product as an integration barrier for them.  Most iOS SDKs are 
> distributed as a single framework and so with that backdrop the friction 
> makes more sense.
> 
> As a result of that I have about 5 bugs open on how to reduce our framework 
> footprint so our tools are easier for our users to integrate.  There are a 
> variety of solutions we use on that, what you see here is one of the saner 
> ones, believe it or not.
> 
> Whether or not the technical requirement makes sense to you, the business 
> case is very clear.  So clear that if scoped were removed we would almost 
> certainly keep the file and its potential threading bugs, over promoting a 
> new framework.  Sales >> code, unfortunately.
> 
Oh, come on — that sounds like removing new private would threaten your 
existence… in this case, afaics a simple search & replace (private -> 
fileprivate) works just fine.
You may not like that solution, but others might not even notice the 
difference. 
Imho the importance of SE-25 has been exaggerated tremendously before it was 
added, and the same seems to happen now, when its removal is discussed.

We shouldn't overdramatise this question, and don't invent arguments to support 
partialities:
Access control worked fine in Swift 2, and fileprivate didn't increase the 
complexity of the language in a way that makes it impossible to teach it.

There are arguments for both positions, and they are valid — but there is a 
huge variance in the perceived importance, and discussion has only very limited 
effect on this.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Jordan Rose via swift-evolution]

> On Mar 23, 2017, at 01:46, Slava Pestov  wrote:
> 
> 
>> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> [Proposal: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md]
>> 
>> I'm definitely in favor of this. Apart from the various motivations 
>> discussed in the proposal, this also allows some changes that could improve 
>> incremental builds: the generated header ("MyApp-Swift.h") wouldn't need to 
>> be regenerated nearly as often with fewer methods exposed to Objective-C. 
>> (There's some nuance here that I don't need to go into right now, and there 
>> are alternate solutions to that problem, but it's nice that the common case 
>> will just put fewer declarations into the header and therefore it would 
>> change less often.)
>> 
>> The migration aspect is a little scary. #selector's Objective-C equivalent 
>> is @selector, which is easy to search for, but #keyPath maps to plain old 
>> strings.
> 
> Are these strings usually literal strings that are passed in to some set of 
> mostly-known selector names, or do people pass them around or even construct 
> them dynamically?

Yeah, that's a saving factor. If someone made a list of all the 
KVC/KVO/bindings APIs and looked for uses in their project, they'd probably get 
most of them (with the minor complication of the argument usually being a key 
path and not just a single key).

Jordan

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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Jordan Rose via swift-evolution]

What happens for people using @objc to choose the class's runtime name? It 
seems unfortunate to conflate that with changed inference.

Jordan


> On Mar 23, 2017, at 02:11, Slava Pestov via swift-evolution 
>  wrote:
> 
> A further benefit of this scheme is that it makes the behavior of @objc on 
> class members consistent between NSObject-derived and Swift-native classes. 
> Right now, it is legal to apply @objc to a _member_ of a Swift-native class; 
> this is what allows Swift-native classes to model @objc protocols and so on. 
> But of course we don’t ever implicitly infer @objc on members of Swift-native 
> classes just based on the calling convention of a method.
> 
> So now we could say that members of non-@objc classes only infer @objc if 
> necessary to fulfill an override or protocol requirement, independently of 
> whether the class is NSObject-derived or not; and @objc can now be applied to 
> an entire class, as long as its NSObject-derived, to get the implicit 
> inference behavior on members.
> 
> Slava
> 
>> On Mar 23, 2017, at 2:06 AM, Slava Pestov  wrote:
>> 
>> Here’s an idea for working around the problem of the lack of static 
>> knowledge during migration. Probably it’s kind of tacky and won’t get much 
>> traction in it’s current form, but it might start some useful discussion at 
>> least.
>> 
>> Right now, @objc when applied to a _class_ is completely useless; if a class 
>> ultimately inherits from NSObject, it is always implicitly @objc, and 
>> applying @objc to a class not rooted in NSObject is always an error. (I 
>> think at some point in the past we allowed @objc classes that _don’t_ 
>> inherit from NSObject, but I don’t know if that even made it into any 
>> released version of Swift, so it’s totally vestigial at this point.) We can 
>> keep this behavior in Swift 3 mode, but in Swift 4 mode, change things so 
>> that @objc applied to a class enables @objc inference for the members of the 
>> class, and the absence of @objc enables the new, more limited inference 
>> behavior outlined in this proposal.
>> 
>> Then the migration story can just be “slap @objc on every NSObject-derived 
>> class and you’re good”. Existing mixed source bases, KVC, and so on would 
>> just work. We could also say that in Swift 4 mode, @objc on an 
>> NSObject-derived class produces a warning asking the developer to consider 
>> making individual members @objc as necessary instead. This would allow a 
>> Swift 4 migration to proceed in two phases — first fix any fallout from 
>> SE-0110 or new string stuff or whatever, and get a working app that builds 
>> and runs in Swift 4 mode, albeit with some warnings. Then they can deal with 
>> marking individual class members as @objc later. We could still have the 
>> option of making it an error to apply @objc to an entire class in a future 
>> release of Swift, if we decide it is beneficial to do so.
>> 
>> Based on feedback, the all-or-nothing nature of the Swift 2->3 migration was 
>> rather painful — mixing and matching 3 and 4 modules will definitely help us 
>> do better the next time around, and allowing a complex change such as this 
>> one to be done piecemeal could be a further step in the right direction.
>> 
>> Slava
>> 
>>> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community, 
>>> 
>>> The review of "SE-0160: Limiting @objc inference" begins now and runs 
>>> through March 28. The proposal is available here:
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at:
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. 
>>> 
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>> * What is your evaluation of the proposal?
>>> * Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>>> * Does this proposal fit well with the feel and direction of Swift?
>>> * If you have you used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>> * How much effort did you put into your review? A glance, a quick reading, 
>>> or an in-depth study? 
>>> 
>>> More information about the Swift evolution process is available at:
>>> https://github.com/apple/swift-evolution/blob/master/process.md 
>>> 
>>> Thanks!
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Itai Ferber via swift-evolution]

Hi Oliver,

Thanks for your comments! We thought about this and we agree overall — 
we will incorporate this suggestion along with others in the next batch 
update as long as nothing prohibitive comes up.


— Itai

On 23 Mar 2017, at 7:49, Oliver Jones wrote:


Like everyone I’m excited by this new proposal.  But…

protocol Codable: Adopted by types to opt into archival. Conformance 
may be automatically derived in cases where all properties are also 
Codable.


… can I make one suggestion.  Please do not repeat the mistakes of 
NSCoding in combining the encoding and decoding into a single 
protocol.  Just as there are Encoder and Decoder classes their should 
be Encodable and Decodable protocols (maybe have an aggregate Codable 
protocol for convenience but do not force it).


My reasoning:

Sometimes you only want to decode or encode and object and not vice 
versa.  This is often the case with Web APIs and JSON serialisation.


Eg:

Often an app only consumes (decodes) JSON encoded objects and never 
writes them out (a read only app for example). So the encode(to:) 
methods are completely redundant and someone adopting Codable should 
not be forced to write them.


If only I had a dollar for all the times I’ve seen this sort of code 
in projects:


class MyClass : NSCoding {
init?(coder: NSCoder) {
  // ... some decoding code
}

func encode(with aCoder: NSCoder) {
   preconditionFailure(“Not implemented”)
}
}


Another example:

Web APIs often take data in a different structure as input (i.e. 
“Request” objects) than they output.  These request objects are 
only ever encoded and never decoded by an application so implementing 
init(from:) is completely redundant.


Personally I think the approach taken by libraries like Wrap 
(https://github.com/johnsundell/wrap) and Unbox 
(https://github.com/JohnSundell/Unbox) is a much better design.  
Encoding and decoding should not be the same protocol.


Yes I understand that Codable could provide no-op (or 
preconditionFailure) protocol extension based default implementations 
of init(from:) and encode(to:) (or try to magic up implementations 
based on the Codable nature of public properties as suggested in the 
proposal) but to me that seems like a hack that is papering over bad 
design.  I think this joint Codable design probably fails the Liskov 
substitution principle too.


So I again implore you to consider splitting Codable into two 
protocols, one for encoding and another for decoding.


Sorry if I’m repeating what other people have already said.  I’ve 
not read every response to this proposal on the list.


Regards



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

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

[Joe Groff via swift-evolution]

> On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>> Alternatives considered
>> 
>> Do nothing and continue to accept this implicit conversion.
> 
> One alternative would be to import CFArray as a typealias for NSArray, etc, 
> erasing the distinction between the two types completely. I did suggest this 
> to Jordan at one point and he pointed out some problems, but I don’t remember 
> them now. Hopefully Jordan can chime in.

I'd prefer this solution as well, especially since toll-free bridged CF types 
are nearly indistinguishable from their NS counterparts at runtime, so trying 
to maintain the distinction for dynamic casts or reflection has historically 
been problematic. Part of the problem is that, as Charlie noted, 
CFArray/Dictionary/Set can take an arbitrary set of retain/release callbacks, 
in which case the resulting container isn't fully NSArray-compatible. I'm not 
sure that happens often enough with CF containers in the SDKs that accounting 
for that case is worth the burden of separating the types.

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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Charlie Monroe via swift-evolution]

> On Mar 23, 2017, at 9:44 AM, Slava Pestov  wrote:
> 
>> 
>> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution 
 > wrote:
 
 
> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution 
> > wrote:
> * What is your evaluation of the proposal?
 
 In favour.
 
 Like others I can foresee there being a bit of pain for some developers, 
 but I think it's worth it to be more explicit about what's going on, and 
 to clean up a feature that's just for supporting a specific other language.
 
 My main concern is on whether things could be made a bit easier; 
 specifically I wonder whether we could introduce an option (to the 
 compiler?) to trigger warnings anywhere there is a possible missing @objc 
 attribute. Basically on any code that produces bridging headers this would 
 give a warning anywhere that @objc would have been inferred in the past, 
 but will no longer be. Of course this will generate a lot of warnings, but 
 it'll be an easier way for developers to go through and make sure they 
 didn't miss something. Xcode could offer this automatically during 
 migration, and the developer can turn it off when they're done. Not 
 perfect, but it may be a little extra help for those most affected?
>>> 
>>> The source compatibility section of the proposal
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
>>>  
>>> 
>>> 
>>> describes the use of NS_DEPRECATED in the generated header for Swift 3 
>>> compatibility mode to get warnings on uses of entities that are implicitly 
>>> @objc but will no longer be in Swift 4. Does that address your concern?
>>> 
>>> I’ve also heard the idea of putting the same warnings into the generated 
>>> Objective-C thunks by NSLog’ing the same information as an opt-in, 
>>> pre-Swift-4-migration step to help catch the tricky cases where an 
>>> Objective-C entrypoint is getting called.
>> 
>> I would very much like that, mostly for catching all scenarios with bindings 
>> on the Mac.
>> 
>> Otherwise, I agree with the proposal, just am a bit concerned with some of 
>> my apps that heavily use bindings…
> 
> Perhaps a better solution than NSLog would be if the existing code coverage 
> support could be modified to instrument @objc thunks, but I don’t know the 
> details well enough to say if this would be practical to implement in the 
> Swift 4 time frame.

What about a symbol for a breakpoint? Like Auto Layout and many other 
frameworks (e.g. break on _NSErrorLog(), etc.) have...




> 
> Slava
> 
>> 
>>> 
>>> - Doug
>>> 
>>> ___
>>> 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 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 23, 2017, at 10:54 AM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> 
>> On Mar 23, 2017, at 2:22 AM, Matt Gallagher via swift-evolution 
>> > wrote:
>> I can't help but feel that this proposal is really misdirected frustration. 
>> Programmers who don't use clusters of tiny types in a single file shouldn't 
>> care about the existence of a scoped access modifier because it shouldn't 
>> affect them – they should use file access modifiers and be done. Yet 
>> apparently, it is file access modifier advocates pushing this proposal.
> 
> It is equally frustrating that those on the opposite side of this proposal 
> keep indicating “just don’t pay attention to it” is an acceptable answer to 
> the language growing an entire axis of confusion to its access control (i.e., 
> a wart) so early in its life.

I think it’s likely that a non-trivial degree of any confusion is related to 
the mistake we made in choosing the names.  Both `fileprivate` and `private` 
include the word `private` in their name.  If we had left `private` alone and 
introduces scoped access with the name `scoped` I think the difference would 
have been much more clear to most people who have been confused.

> 
> Sincerely,
> Zachary Waldowski
> Sent from my Mac
> 
> ___
> 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

Re: [swift-evolution] Swift null safety questions

[Joe Groff via swift-evolution]

> On Mar 22, 2017, at 7:25 PM, Elijah Johnson  wrote:
> 
> On March 22, 2017 at 8:41:25 PM, Joe Groff (jgr...@apple.com 
> ) wrote:
>> 
>> > On Mar 22, 2017, at 4:07 PM, Elijah Johnson > > > wrote: 
>> > 
>> > Hi, 
>> > 
>> > Note that this thread has branched off a bit, so my latest proposal and 
>> > the “head” of this thread can be found at 
>> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html
>> >  
>> > 
>> >  
>> > 
>> > 
>> > 
>> > Can you give an example of this corruption which would be exploitable in a 
>> > web server context? An example where, having caught the force-unwrap or 
>> > other precondition fatalError, that the web server would face more danger 
>> > from continued execution that it would loose by crashing? 
>> > 
>> > The optional has been triggered, the request has been stopped, and 
>> > incoming requests are going to a new process, but there are a few threads 
>> > open still finishing what they were doing - I’d like to see a good example 
>> > of the danger caused by a real “inconsistency”. Lets assume also that all 
>> > objects shared between threads are Swift objects and not “UnsafePointers”, 
>> > which is a very fair assumtion for a web server. Java even allows native 
>> > access and they don’t even crash there. 
>> 
>> When considering security threats, we have to take the presence of an 
>> exploit as given until we prove otherwise. A precondition failure indicates 
>> a logic error somewhere in the program, and while safe Swift abstractions 
>> are intended not to lead to memory unsafety in the face of precondition 
>> failures, there's plenty of relatively young, unsafe code below the hood in 
>> the implementations of those abstractions, written by humans who make 
>> mistakes. Whatever lurking security bugs there may be, they're more likely 
>> to be exploitable if you're already in a situation where assumptions have 
>> been violated. 
>> 
>> > I’m sorry, but I completely fail to grasp the danger as being > crashing. 
>> 
>> Crashing is inconvenient. The user may have to retry their request or 
>> relaunch their app. Security breaches or data corruption are disasters that 
>> can have unbounded impact and cost—you can't undisclose sensitive data. 
>> 
>> > I’d be interested to know who these web server developers (ex. Kitura, 
>> > Vapor) are targeting without any form of crash handling and if they read 
>> > these threads. It really limits the pool of developers more so than on 
>> > apps because a single crash on the app ie equivelant to a failed request, 
>> > not a crashed web server. I realize you are not competing with Java, but I 
>> > do not see yet the compelling reason for no crash handling. 
>> > 
>> > The “actors” with thread pool and proccesses is one idea, but I think 
>> > these servers are aiming also for speed and scaleability - don’t know if 
>> > they would accept this model. I know that it does get used, and do work 
>> > for a company that uses it on their backend (just plain Java, not sep. 
>> > processes). Their front-end probably runs like a pre-fork server, but Java 
>> > is so stable that there is simply no need for that. 
>> 
>> You can use processes for fault isolation today, and that will have some 
>> cost. At Swift's current maturity level, that's really probably the only 
>> responsible isolation strategy. The goal of "actors" would be to get most of 
>> the benefits of processes through language-level isolation without paying 
>> the full cost of processes. 
>> 
>> -Joe
> 
> 
> I have no personal objection to actors or processes or anything else. I would 
> just emphasize that the webservers in existence for Swift (and quite well 
> funded) are right now on a “crash the whole thing” model AFAIK. I don’t know 
> if they will be able to get by with catching all the precondition failures in 
> testing - maybe they will - maybe not, but I see people either wisely turning 
> down Swift for web development or getting their first crash as a “zero-day” 
> system down event where some guy has to ssh in and actually start the server 
> back up.
> 
I haven't worked directly with server people that much personally, but on the 
opportunities when I have been able to talk to people working in this space, it 
sounds like they definitely want something better.
> But whatever the fix is, or nothing, they (developers of Perfect, Kitura, 
> Vapor, etc) will have to like it and implement it. If they’re not interested, 
> I’m not starting a development company to compete.
> 
I don't see a problem with people developing frameworks to the best of the 
platform's ability today and refining their approach as new capabilities get 
developed.
> And also the development time is so short on my idea that you basically just 
> have to approve it and the 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Zach Waldowski via swift-evolution]

> On Mar 23, 2017, at 2:22 AM, Matt Gallagher via swift-evolution 
>  wrote:
> I can't help but feel that this proposal is really misdirected frustration. 
> Programmers who don't use clusters of tiny types in a single file shouldn't 
> care about the existence of a scoped access modifier because it shouldn't 
> affect them – they should use file access modifiers and be done. Yet 
> apparently, it is file access modifier advocates pushing this proposal.

It is equally frustrating that those on the opposite side of this proposal keep 
indicating “just don’t pay attention to it” is an acceptable answer to the 
language growing an entire axis of confusion to its access control (i.e., a 
wart) so early in its life.

Sincerely,
Zachary Waldowski
Sent from my Mac

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 23, 2017, at 10:51 AM, Andrey Fidrya via swift-evolution 
>  wrote:
> 
>> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution 
>>  wrote:
>> I strongly prefer that “private” should mean “visible in the current file”.
>> I am ambivalent between eliminating the scoped access level or renaming it 
>> “scoped”, as long as “private” once more denotes file-level visibility.
> 
> Imo opinions are split 50/50 on whether access levels should be file based or 
> type based, it's endless debate.
> What are the downsides of covering both cases? I.e. making private "visible 
> in the current file and type extensions".
> This concept is not that hard to teach and doesn't require complex and 
> syntactically verbose access level systems.

I can’t speak for others, but I want scoped access not type-based access.  
Type-based access control solves different problems than scoped access control 
and isn’t under discussion in this review.

> 
> Andrey
> 
> ___
> 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Andrey Fidrya via swift-evolution]

> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> I strongly prefer that “private” should mean “visible in the current file”.
> I am ambivalent between eliminating the scoped access level or renaming it 
> “scoped”, as long as “private” once more denotes file-level visibility.

Imo opinions are split 50/50 on whether access levels should be file based or 
type based, it's endless debate.
What are the downsides of covering both cases? I.e. making private "visible in 
the current file and type extensions".
This concept is not that hard to teach and doesn't require complex and 
syntactically verbose access level systems.

Andrey

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote:

> We will get static linking at some point in the near future.
Static linking does not fix this issue. Just change "framework" to ".a".

> If we wait until we get submodules, we won't be able to revisit. This is 
> probably our last chance to "remove" a feature. Submodules can always add 
> features down the way.
Maybe submodules will solve this issue, maybe not.  But submodules are *much* 
more complex than scoped access:

* Performance.  This is hot code we compile with WMO.  Moving it into a 
submodule could reduce visibility for optimization in a way that causes a 
performance regression.  In particular, we know that specialization of T is a 
performance requirement, it isn't clear whether that would be preserved.  Does 
WMO provide the same visibility across submodules?  Nobody knows.

* Namespacing.  It's possible that one program may ship 3-4 versions of this 
code because each dependency has a slightly different version under our current 
samizdat process.  It is not clear whether submodules would avoid the 
"duplicate symbols" issue from C/ObjC.  Xiaodi seems quite concerned about a 
related "duplicate functions" problem involved with private today, doubling 
down on that is not a good idea.

* It is not clear whether submodules are from an objectcode point of view 
merged into the parent library or kept as individual libraries

* It is not clear from a .swiftmodule point of view whether submodules are 
merged into the parent module or distributed as .swiftmodules / .swiftdocs

* Not clear how much ABI impact there is from submodules at a time when we are 
supposed to be trying to stabilize it

I would love to believe that a proposal on submodules will come through having 
solutions to all these issues and many more, then we will implement it and all 
sing kumbayah.  But we are a long distance from that, and it may never happen 
at all, certainly we cannot evaluate proposals that haven't been written.  
Meanwhile we have a solution in the hand.

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

Re: [swift-evolution] Overriding specific methods when adopting protocols with extension

[Brian King via swift-evolution]

Hey Iman, This is a known bug SR-103. It certainly has caught a few people
off guard. Dale Buckley is working on an evolution proposal that would
allow the bug to be fixed:

Proposal:
https://gist.github.com/dlbuckley/1858a7c0b5c027248fe16171d23ba01d

Conversation on the Proposal:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033787.html

The only work around at this time is to make sure that your base class
implements all methods in the protocol.

Brian King


On Thu, Mar 23, 2017 at 11:15 AM, Iman Zarrabian via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi,
> This is my first contribution to this list so I’m a little nervous.
> I’ve been refactoring some code in one of our internal frameworks and
> noticed something I didn’t noticed about protocols before.
> Maybe I’m missing the big picture here but I’ll expose the issue to you
> anyway.
> Consider these protocols and classes declarations :
>
> protocol Foo {
> func bar()
> func specificBar()
> func moreBar()
> }
>
> extension Foo {
> func specificBar() {
> print("default specificBar implementation")
> }
> }
>
> extension UIView: Foo {
> func bar() {
> print("uiview default bar")
> specificBar()
> moreBar()
> }
>
>
> func moreBar() {
> print("UIView is foo compliant and implements moreBar function")
> }
> }
>
> class CustomView: UIView {
> func startJob() {
> bar()
> }
>
>
> func specificBar() {
> print("CustomView specific bar implementation")  //This is the
> implementation I want for specificBar but this is not the one picked at
> runtime.
> }
> }
>
>
> let view = CustomView()
> view.startJob()
>
> //Prints :
> //uiview default bar
> *//default specificBar implementation*
> //UIView is foo compliant and implements moreBar function
>
> I was wondering if it is a good idea to give the CustomView class the
> power to be more specific about it’s parent protocol adoption.
>
> It seems to me that implementation of a protocol method cannot be easily
> changed by subclasses of the class that actually adopts the protocol in the
> first place. IMO one way to achieve the kind of specialization I’m trying
> to do is to create two protocols and another would be to implement a
> version of specificBar in the superclass (UIView here)
>
> But does it make sense to consider some kind of cherry picking (with a new
> keyword) for those methods we want to implement more precisely than the one
> provided on the protocol extension?
> Consider this new code for CustomView :
>
> class CustomView: UIView {
> func startJob() {
> bar()
> }
>
>
> override adoption func specificBar() {  //or override protocol =>
> implements a method from a protocol adopted by the superclass
> print("CustomView specificBar implementation")
> }
> }
>
> let view = CustomView()
> view.startJob()
>
> //Would print :
> //uiview default bar
> *//CustomView specificBar implementation*
> //UIView is foo compliant and implements moreBar function
>
> I would appreciate your feedback.
>
> --
> Iman Zarrabian
> @imanzarrabian
>
> ___
> 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

[swift-evolution] Overriding specific methods when adopting protocols with extension

[Iman Zarrabian via swift-evolution]

Hi,  
This is my first contribution to this list so I’m a little nervous. 
I’ve been refactoring some code in one of our internal frameworks and noticed 
something I didn’t noticed about protocols before. 
Maybe I’m missing the big picture here but I’ll expose the issue to you anyway.
Consider these protocols and classes declarations :

protocol Foo {
func bar()
func specificBar()
func moreBar()
}

extension Foo {
func specificBar() {
print("default specificBar implementation")
}
}

extension UIView: Foo {
func bar() {
print("uiview default bar")
specificBar()
moreBar()
}

func moreBar() {
print("UIView is foo compliant and implements moreBar function")
}
}

class CustomView: UIView {
func startJob() {
bar()
}

func specificBar() {
print("CustomView specific bar implementation")  //This is the 
implementation I want for specificBar but this is not the one picked at runtime.
}
}


let view = CustomView()
view.startJob()

//Prints :
//uiview default bar
//default specificBar implementation
//UIView is foo compliant and implements moreBar function

I was wondering if it is a good idea to give the CustomView class the power to 
be more specific about it’s parent protocol adoption.

It seems to me that implementation of a protocol method cannot be easily 
changed by subclasses of the class that actually adopts the protocol in the 
first place. IMO one way to achieve the kind of specialization I’m trying to do 
is to create two protocols and another would be to implement a version of 
specificBar in the superclass (UIView here)

But does it make sense to consider some kind of cherry picking (with a new 
keyword) for those methods we want to implement more precisely than the one 
provided on the protocol extension?
Consider this new code for CustomView : 

class CustomView: UIView {
func startJob() {
bar()
}

override adoption func specificBar() {  //or override protocol => 
implements a method from a protocol adopted by the superclass
print("CustomView specificBar implementation")
}
}

let view = CustomView()
view.startJob()

//Would print :
//uiview default bar
//CustomView specificBar implementation
//UIView is foo compliant and implements moreBar function

I would appreciate your feedback.

--
Iman Zarrabian
@imanzarrabian___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Oliver Jones via swift-evolution]

Like everyone I’m excited by this new proposal.  But…

> protocol Codable: Adopted by types to opt into archival. Conformance may be 
> automatically derived in cases where all properties are also Codable.

… can I make one suggestion.  Please do not repeat the mistakes of NSCoding in 
combining the encoding and decoding into a single protocol.  Just as there are 
Encoder and Decoder classes their should be Encodable and Decodable protocols 
(maybe have an aggregate Codable protocol for convenience but do not force it).

My reasoning:

Sometimes you only want to decode or encode and object and not vice versa.  
This is often the case with Web APIs and JSON serialisation.  

Eg:

Often an app only consumes (decodes) JSON encoded objects and never writes them 
out (a read only app for example). So the encode(to:) methods are completely 
redundant and someone adopting Codable should not be forced to write them.  

If only I had a dollar for all the times I’ve seen this sort of code in 
projects:

class MyClass : NSCoding {
init?(coder: NSCoder) {
  // ... some decoding code
}

func encode(with aCoder: NSCoder) {
   preconditionFailure(“Not implemented”)
}
}


Another example: 

Web APIs often take data in a different structure as input (i.e. “Request” 
objects) than they output.  These request objects are only ever encoded and 
never decoded by an application so implementing init(from:) is completely 
redundant.

Personally I think the approach taken by libraries like Wrap 
(https://github.com/johnsundell/wrap ) and 
Unbox (https://github.com/JohnSundell/Unbox 
) is a much better design.  Encoding and 
decoding should not be the same protocol.

Yes I understand that Codable could provide no-op (or preconditionFailure) 
protocol extension based default implementations of init(from:) and encode(to:) 
(or try to magic up implementations based on the Codable nature of public 
properties as suggested in the proposal) but to me that seems like a hack that 
is papering over bad design.  I think this joint Codable design probably fails 
the Liskov substitution principle too.

So I again implore you to consider splitting Codable into two protocols, one 
for encoding and another for decoding.

Sorry if I’m repeating what other people have already said.  I’ve not read 
every response to this proposal on the list.

Regards





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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 23, 2017, at 1:22 AM, Matt Gallagher via swift-evolution 
>  wrote:
> 
>> What is your evaluation of the proposal?
> 
> I disagree with this proposal. It removes functionality that I actively use.
> 
> This proposal aims to revert SE-0025 without really addressing the aims of 
> that proposal, merely dismissing the result as "actively harmful" without 
> defining what that means. SE-0159 raises the complaint that "private" is 
> syntactically more natural default while "fileprivate" is a more useful 
> default. On this point, I agree but the proposal is not about mere renaming.
> 
> The other discussion in the proposal is to ask the questions:
> 
>   1. is that distinction between private and fileprivate actively used by 
> the larger community of Swift developers
> 
>   2. if it were used pervasively, would it be worth the cognitive load 
> and complexity of keeping two very similar access levels in the language?
> 
> Fair questions but despite the proposal claiming "This proposal argues that 
> answer to both questions is no", the proposal offers no *arguments* for the 
> answers, it merely states a position.
> 
> For this reason, I feel the proposal is unreasonably dismissive of the aims 
> of SE-0025.
> 
> Frankly, both these questions have subjective answers based on how 
> programmers tend to design their programs. I personally like to build 
> functionality using lots of very tiny types (many just 4 or 5 lines long), 
> therefore, I frequently put multiple types in the same file (they're part of 
> the same functionality, even if they're not part of the same type). However, 
> I want to have actual interfaces and implementation hiding between them 
> otherwise there's always the possibility of accidentally abusing the 
> interface to each type. An access modifier narrower than the file, like the 
> current scoped "private", is the *only* way to achieve this.
> 
> Reverting SE-0025 means the only way to have enforced interfaces between 
> types is to place them in separate files. This is counterproductive for tiny 
> types that form a single conceptual entity. Separate files also requires 
> whole-program optimization for optimal performance.
> 
> The only conclusion I can make is that programmers in favor of this proposal 
> simply don't program this way. However, I find it insulting that this 
> proposal is essentially saying: your way of designing and structuring 
> programs is wrong; you must use big monolithic types in their own files and 
> endure reduced compilation (whole-program optimization) or runtime 
> performance (no inlining between files with whole-program off).
> 
> I can't help but feel that this proposal is really misdirected frustration. 
> Programmers who don't use clusters of tiny types in a single file shouldn't 
> care about the existence of a scoped access modifier because it shouldn't 
> affect them – they should use file access modifiers and be done. Yet 
> apparently, it is file access modifier advocates pushing this proposal.
> 
> It really seems like the existence of a scoped access modifier is taking the 
> blame for people's frustration that the simpler keyword ("private") is a less 
> good default than the clunky keyword ("fileprivate"). I personally agree that 
> the behavior or "fileprivate" is probably a better default so I understand 
> the desire to give "private" back that meaning again. However, I don't want 
> to lose a scoped access modifier because it is *useful* (for reasons of both 
> project structure and compilation or runtime performance).
> 
> So... thumbs down from me. However, if someone wants to rename fileprivate -> 
> private and rename private -> scope (or something) I'd be more supportive.

Huge +1 to everything Matt says here.  

Elsewhere it has been argued that submodules allowing for a submodule scope can 
be combined with file scope to address some of the use cases for scoped access 
control.  This is true, but I want to point out that this combination most 
definitely does not address the use cases Matt describes here.  I often also 
create small types which are in the same file with other types and benefit from 
scoped access control.  As Matt points out, there simply isn’t any other way to 
address this use case.  It would be a shame to see Swift revert to not properly 
supporting this style of code.

It is also true that submodules (depending on their design) can address some of 
the use cases for file level scope.  In fact some people have suggested we 
might be able to drop file level scope after introducing submodules.  I 
wouldn’t want to see us do that (both are useful), but forced to choose between 
file scope and lexical scope in a language with submodules I may well choose 
lexical scope.  

Even if we assume that we want to eliminate either file or lexical scope I 
think it is preliminary to make a decision about which to eliminate.  The 
community should make this decision when we 

Re: [swift-evolution] Smart KeyPaths

[Karim Nassar via swift-evolution]

> I guess I just don't understand why people seem so eager to change this 
> syntax. The biggest complaint seems to be that it's too lightweight and 
> natural; they're worried they might not realize they're using this big, scary 
> new feature. But this feature simply *isn't* big and scary! It's new right 
> now, but in a few years it's going to feel very natural.
> 
> […]
> 
> Key paths are about as nonthreatening as a syntax can be. They overload some 
> things, but the type checker will catch most overloading mistakes. Other than 
> that, there's just no justification for the level of anxiety people seem to 
> have. They don't break type safety, they don't involve unusual or non-obvious 
> control flow, they don't trap, and they can be explained in a couple of 
> sentences. If ever there was a candidate for a lightweight syntax, this is 
> it. 
> 
> As the protest sign says: "I want YOU to stop being afraid". I have yet to be 
> convinced that this feature is too dangerous or mistake-prone to allow the 
> simple, natural syntax the authors propose. If I'm wrong, then by all means 
> show me I'm wrong, but I just don't see it.


I don’t have a strong opinion on the sigil question one way or another, but I’m 
not sure it’s fair to categorize the sigil proponents as being afraid of the 
feature. I do find the argument that some kind of sigil to clarify the 
construction-site of a KeyPath somewhat compelling.

KeyPath declarations as described in the proposal are fairly unique in that 
they have all the appearance of accessing a property value on a type, but are 
in fact a mechanism for “creating” (referencing?) a type entirely different 
from their face-value. That is: a KeyPath shares most of its spelling with the 
value that it points to, and absent knowledge of the programmer’s *intent* it’s 
not immediately obvious whether code is accessing a value or creating a 
KeyPath. They are references to a named member of a type which are derived by 
their name.

IMHO, it’s not *that* unreasonable to want a spelling variation to call 
attention to this difference.

In any case, as I said, I’m not strongly opinionated on this matter, but 
perhaps it *is* worth considering some sigil we could apply to both KeyPath and 
function assignments to clarify both sites in the same way.

—Karim
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Allen Zeng via swift-evolution]

> What is your evaluation of the proposal?
-1.

Plenty of excellent points are made in the threads, which clearly
shows that there are many users who want to use the file based private
feature only, and many users who want to keep everything _really_
private, unless they need to be exposed at a file scope.

For this reason alone, reverting to Swift 2 behaviour is unwise.
Keeping `fileprivate` as is is also a better choice because it very
unambiguously expresses its meaning - a great quality Swift strives
for.

Other reasons that lead me to the decision are the benefits of
encapsulation, churn. Others have made very good arguments already.


> Is the problem being addressed significant enough to warrant a change to 
> Swift?
No.


> Does this proposal fit well with the feel and direction of Swift?
No.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
No other language that I know of behaves this way with the private.
That said, Swift should change things where it makes sense. However I
don't think this proposal is an improvement over how other languages
implement it.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Read all the threads
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift null safety questions

[Alex Blewitt via swift-evolution]

> On 23 Mar 2017, at 02:25, Elijah Johnson via swift-evolution 
>  wrote:
> 
> On March 22, 2017 at 8:41:25 PM, Joe Groff (jgr...@apple.com 
> ) wrote:
>> 
>> > On Mar 22, 2017, at 4:07 PM, Elijah Johnson > > > wrote: 
>> > 
>> > Hi, 
>> > 
>> > Note that this thread has branched off a bit, so my latest proposal and 
>> > the “head” of this thread can be found at 
>> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html
>> >  
>> > 
>> >  
>> > 
>> > 
>> > 
>> > Can you give an example of this corruption which would be exploitable in a 
>> > web server context? An example where, having caught the force-unwrap or 
>> > other precondition fatalError, that the web server would face more danger 
>> > from continued execution that it would loose by crashing? 
>> > 
>> > The optional has been triggered, the request has been stopped, and 
>> > incoming requests are going to a new process, but there are a few threads 
>> > open still finishing what they were doing - I’d like to see a good example 
>> > of the danger caused by a real “inconsistency”. Lets assume also that all 
>> > objects shared between threads are Swift objects and not “UnsafePointers”, 
>> > which is a very fair assumtion for a web server. Java even allows native 
>> > access and they don’t even crash there. 
>> 
>> When considering security threats, we have to take the presence of an 
>> exploit as given until we prove otherwise. A precondition failure indicates 
>> a logic error somewhere in the program, and while safe Swift abstractions 
>> are intended not to lead to memory unsafety in the face of precondition 
>> failures, there's plenty of relatively young, unsafe code below the hood in 
>> the implementations of those abstractions, written by humans who make 
>> mistakes. Whatever lurking security bugs there may be, they're more likely 
>> to be exploitable if you're already in a situation where assumptions have 
>> been violated. 
>> 
>> > I’m sorry, but I completely fail to grasp the danger as being > crashing. 
>> 
>> Crashing is inconvenient. The user may have to retry their request or 
>> relaunch their app. Security breaches or data corruption are disasters that 
>> can have unbounded impact and cost—you can't undisclose sensitive data. 
>> 
>> > I’d be interested to know who these web server developers (ex. Kitura, 
>> > Vapor) are targeting without any form of crash handling and if they read 
>> > these threads. It really limits the pool of developers more so than on 
>> > apps because a single crash on the app ie equivelant to a failed request, 
>> > not a crashed web server. I realize you are not competing with Java, but I 
>> > do not see yet the compelling reason for no crash handling. 
>> > 
>> > The “actors” with thread pool and proccesses is one idea, but I think 
>> > these servers are aiming also for speed and scaleability - don’t know if 
>> > they would accept this model. I know that it does get used, and do work 
>> > for a company that uses it on their backend (just plain Java, not sep. 
>> > processes). Their front-end probably runs like a pre-fork server, but Java 
>> > is so stable that there is simply no need for that. 
>> 
>> You can use processes for fault isolation today, and that will have some 
>> cost. At Swift's current maturity level, that's really probably the only 
>> responsible isolation strategy. The goal of "actors" would be to get most of 
>> the benefits of processes through language-level isolation without paying 
>> the full cost of processes. 
>> 
>> -Joe
> 
> 
> I have no personal objection to actors or processes or anything else. I would 
> just emphasize that the webservers in existence for Swift (and quite well 
> funded) are right now on a “crash the whole thing” model AFAIK. I don’t know 
> if they will be able to get by with catching all the precondition failures in 
> testing - maybe they will - maybe not, but I see people either wisely turning 
> down Swift for web development or getting their first crash as a “zero-day” 
> system down event where some guy has to ssh in and actually start the server 
> back up.
> 
> But whatever the fix is, or nothing, they (developers of Perfect, Kitura, 
> Vapor, etc) will have to like it and implement it. If they’re not interested, 
> I’m not starting a development company to compete. And also the development 
> time is so short on my idea that you basically just have to approve it and 
> the development time for it is hours not months or years. Just add a 
> fatalError function override and any c developer could have it done in 
> minutes like this guy https://github.com/ankurp/unsafe-swift 
>  (not endorsing the post, just 
> showing evidence that setjmp and longjmp work fine with swift).
> 

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Slava Pestov via swift-evolution]

A further benefit of this scheme is that it makes the behavior of @objc on 
class members consistent between NSObject-derived and Swift-native classes. 
Right now, it is legal to apply @objc to a _member_ of a Swift-native class; 
this is what allows Swift-native classes to model @objc protocols and so on. 
But of course we don’t ever implicitly infer @objc on members of Swift-native 
classes just based on the calling convention of a method.

So now we could say that members of non-@objc classes only infer @objc if 
necessary to fulfill an override or protocol requirement, independently of 
whether the class is NSObject-derived or not; and @objc can now be applied to 
an entire class, as long as its NSObject-derived, to get the implicit inference 
behavior on members.

Slava

> On Mar 23, 2017, at 2:06 AM, Slava Pestov  wrote:
> 
> Here’s an idea for working around the problem of the lack of static knowledge 
> during migration. Probably it’s kind of tacky and won’t get much traction in 
> it’s current form, but it might start some useful discussion at least.
> 
> Right now, @objc when applied to a _class_ is completely useless; if a class 
> ultimately inherits from NSObject, it is always implicitly @objc, and 
> applying @objc to a class not rooted in NSObject is always an error. (I think 
> at some point in the past we allowed @objc classes that _don’t_ inherit from 
> NSObject, but I don’t know if that even made it into any released version of 
> Swift, so it’s totally vestigial at this point.) We can keep this behavior in 
> Swift 3 mode, but in Swift 4 mode, change things so that @objc applied to a 
> class enables @objc inference for the members of the class, and the absence 
> of @objc enables the new, more limited inference behavior outlined in this 
> proposal.
> 
> Then the migration story can just be “slap @objc on every NSObject-derived 
> class and you’re good”. Existing mixed source bases, KVC, and so on would 
> just work. We could also say that in Swift 4 mode, @objc on an 
> NSObject-derived class produces a warning asking the developer to consider 
> making individual members @objc as necessary instead. This would allow a 
> Swift 4 migration to proceed in two phases — first fix any fallout from 
> SE-0110 or new string stuff or whatever, and get a working app that builds 
> and runs in Swift 4 mode, albeit with some warnings. Then they can deal with 
> marking individual class members as @objc later. We could still have the 
> option of making it an error to apply @objc to an entire class in a future 
> release of Swift, if we decide it is beneficial to do so.
> 
> Based on feedback, the all-or-nothing nature of the Swift 2->3 migration was 
> rather painful — mixing and matching 3 and 4 modules will definitely help us 
> do better the next time around, and allowing a complex change such as this 
> one to be done piecemeal could be a further step in the right direction.
> 
> Slava
> 
>> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community, 
>> 
>> The review of "SE-0160: Limiting @objc inference" begins now and runs 
>> through March 28. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at:
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. 
>> 
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> * What is your evaluation of the proposal?
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> * Does this proposal fit well with the feel and direction of Swift?
>> * If you have you used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study? 
>> 
>> More information about the Swift evolution process is available at:
>>  https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thanks!
>> 
>> -Chris Lattner
>> Review Manager
>> ___
>> 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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Slava Pestov via swift-evolution]

Here’s an idea for working around the problem of the lack of static knowledge 
during migration. Probably it’s kind of tacky and won’t get much traction in 
it’s current form, but it might start some useful discussion at least.

Right now, @objc when applied to a _class_ is completely useless; if a class 
ultimately inherits from NSObject, it is always implicitly @objc, and applying 
@objc to a class not rooted in NSObject is always an error. (I think at some 
point in the past we allowed @objc classes that _don’t_ inherit from NSObject, 
but I don’t know if that even made it into any released version of Swift, so 
it’s totally vestigial at this point.) We can keep this behavior in Swift 3 
mode, but in Swift 4 mode, change things so that @objc applied to a class 
enables @objc inference for the members of the class, and the absence of @objc 
enables the new, more limited inference behavior outlined in this proposal.

Then the migration story can just be “slap @objc on every NSObject-derived 
class and you’re good”. Existing mixed source bases, KVC, and so on would just 
work. We could also say that in Swift 4 mode, @objc on an NSObject-derived 
class produces a warning asking the developer to consider making individual 
members @objc as necessary instead. This would allow a Swift 4 migration to 
proceed in two phases — first fix any fallout from SE-0110 or new string stuff 
or whatever, and get a working app that builds and runs in Swift 4 mode, albeit 
with some warnings. Then they can deal with marking individual class members as 
@objc later. We could still have the option of making it an error to apply 
@objc to an entire class in a future release of Swift, if we decide it is 
beneficial to do so.

Based on feedback, the all-or-nothing nature of the Swift 2->3 migration was 
rather painful — mixing and matching 3 and 4 modules will definitely help us do 
better the next time around, and allowing a complex change such as this one to 
be done piecemeal could be a further step in the right direction.

Slava

> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community, 
> 
> The review of "SE-0160: Limiting @objc inference" begins now and runs through 
> March 28. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. 
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study? 
> 
> More information about the Swift evolution process is available at:
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thanks!
> 
> -Chris Lattner
> Review Manager
> ___
> 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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Slava Pestov via swift-evolution]

> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md]
> 
> I'm definitely in favor of this. Apart from the various motivations discussed 
> in the proposal, this also allows some changes that could improve incremental 
> builds: the generated header ("MyApp-Swift.h") wouldn't need to be 
> regenerated nearly as often with fewer methods exposed to Objective-C. 
> (There's some nuance here that I don't need to go into right now, and there 
> are alternate solutions to that problem, but it's nice that the common case 
> will just put fewer declarations into the header and therefore it would 
> change less often.)
> 
> The migration aspect is a little scary. #selector's Objective-C equivalent is 
> @selector, which is easy to search for, but #keyPath maps to plain old 
> strings.

Are these strings usually literal strings that are passed in to some set of 
mostly-known selector names, or do people pass them around or even construct 
them dynamically?

Slava

> For those with Mac apps, properties might even be referenced in Interface 
> Builder using Cocoa Bindings. But limiting the change to Swift 4 mode seems 
> acceptable to me—at least it's a known change that people will be able to 
> point to when things stop working.
> 
> Jordan
> ___
> 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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Slava Pestov via swift-evolution]

> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
>> 
>> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution 
  wrote:
 * What is your evaluation of the proposal?
>>> 
>>> In favour.
>>> 
>>> Like others I can foresee there being a bit of pain for some developers, 
>>> but I think it's worth it to be more explicit about what's going on, and to 
>>> clean up a feature that's just for supporting a specific other language.
>>> 
>>> My main concern is on whether things could be made a bit easier; 
>>> specifically I wonder whether we could introduce an option (to the 
>>> compiler?) to trigger warnings anywhere there is a possible missing @objc 
>>> attribute. Basically on any code that produces bridging headers this would 
>>> give a warning anywhere that @objc would have been inferred in the past, 
>>> but will no longer be. Of course this will generate a lot of warnings, but 
>>> it'll be an easier way for developers to go through and make sure they 
>>> didn't miss something. Xcode could offer this automatically during 
>>> migration, and the developer can turn it off when they're done. Not 
>>> perfect, but it may be a little extra help for those most affected?
>> 
>> The source compatibility section of the proposal
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
>> 
>> describes the use of NS_DEPRECATED in the generated header for Swift 3 
>> compatibility mode to get warnings on uses of entities that are implicitly 
>> @objc but will no longer be in Swift 4. Does that address your concern?
>> 
>> I’ve also heard the idea of putting the same warnings into the generated 
>> Objective-C thunks by NSLog’ing the same information as an opt-in, 
>> pre-Swift-4-migration step to help catch the tricky cases where an 
>> Objective-C entrypoint is getting called.
> 
> I would very much like that, mostly for catching all scenarios with bindings 
> on the Mac.
> 
> Otherwise, I agree with the proposal, just am a bit concerned with some of my 
> apps that heavily use bindings…

Perhaps a better solution than NSLog would be if the existing code coverage 
support could be modified to instrument @objc thunks, but I don’t know the 
details well enough to say if this would be practical to implement in the Swift 
4 time frame.

Slava

> 
>> 
>>  - Doug
>> 
>> ___
>> 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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Slava Pestov via swift-evolution]

> On Mar 22, 2017, at 10:55 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> * What is your evaluation of the proposal?
> 
> I'm going to have to come down on the "no" side on this one.
> 
> I'm actually not worried about methods so much as properties. KVC is 
> completely untyped on the Objective-C side, and there are several different 
> mechanisms there which use KVC with poorly validated external strings, like 
> bindings, sort descriptors, and predicates. Tons of migration errors are 
> going to escape into production if we do this, and undetectable mistakes are 
> going to continue on an ongoing basis. 
> 
> Have we explored alternate implementations? For instance, when the compiler 
> can statically determine all of the call sites for an `@objc` member, could 
> we emit *only* an implementation with the Objective-C calling convention and 
> call that directly from Swift?

This would incur bridging overhead for collections I believe. We really do want 
to use the Swift calling convention whenever we know the method is defined in 
Swift, even if happens to be exposed to Objective-C. It would be unfortunate if 
there was an unpredictable performance cliff encountered because of @objc 
inference.

> Have you evaluated applying different rules to methods and properties? Have 
> you considered a deprecation cycle (for instance, having Swift 4 thunks log a 
> warning that they're going away in Swift 5)?

I’m not sure how this could work. If we emit an unconditional warning on every 
method that has an Objective-C compatible signature but is not marked as @objc, 
how would the user acknowledge the warning and say “OK, I don’t really want 
inference here?” Would the only way to opt out of the warning be to write 
@nonobjc everywhere?

> Or is the real motivation that, code size issues aside, you think these 
> members ought to be explicitly marked `@objc` for philosophical reasons? If 
> so, how many times do you want people to say so? You already have to 
> explicitly inherit from an `@objc` base class; you already have to specify 
> `dynamic` to avoid optimizations; now you also have to mark individual 
> members `@objc`? Would you like the request for bridging notarized and filed 
> in triplicate?

The ‘accidental selector name clash’ argument is a good one I think; if you’re 
designing a pure Swift class that happens to inherit from NSObject, it might be 
confusing to a user if they define methods named foo(_: Int) and foo(_: String) 
and get a compiler error.

It would be interesting to get some more data on the size overhead of @objc 
thunks from real codebases, but I think the difficulty there is ascertaining 
which thunks are ‘required’ and which ones are not (which of course is also the 
core of your objection to the feature, if I understand; if we could perfectly 
determine which thunks were needed statically, the migration story would be far 
less of a concern).

Slava

> I can understand the impulse to require it explicitly on `public` members, 
> but on the other hand, if you *do* accidentally publish a member as `@objc`, 
> what's the harm? Is there any non-breaking change you can make to a 
> `@nonobjc` method which wouldn't be legal on an `@objc` one? Or can you just 
> deprecate the `@objc` version and move on?
> 
> Overall, I think this is far too bureaucratic, and I'm not convinced that 
> either the technical or the theoretical justification is compelling. Maybe 
> you've eliminated some of the possibilities I've suggested or there are 
> negative effects I don't understand, but right now, I don't see it. 
> 
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> I'm uncertain. 
> 
>> * Does this proposal fit well with the feel and direction of Swift?
> 
> It fits with certain goals, like making public APIs explicit, but not with 
> others, like avoiding boilerplate. 
> 
>> * If you have you used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> I haven't used anything with such deep foreign-language bridging as Swift. 
> 
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> Quick reading during a hockey game, so please forgive any oversights. 
> 
> 
> Sent from my iPad
> ___
> 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

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Matt Gallagher via swift-evolution]

> What is your evaluation of the proposal?

I disagree with this proposal. It removes functionality that I actively use.

This proposal aims to revert SE-0025 without really addressing the aims of that 
proposal, merely dismissing the result as "actively harmful" without defining 
what that means. SE-0159 raises the complaint that "private" is syntactically 
more natural default while "fileprivate" is a more useful default. On this 
point, I agree but the proposal is not about mere renaming.

The other discussion in the proposal is to ask the questions:

1. is that distinction between private and fileprivate actively used by 
the larger community of Swift developers

2. if it were used pervasively, would it be worth the cognitive load 
and complexity of keeping two very similar access levels in the language?

Fair questions but despite the proposal claiming "This proposal argues that 
answer to both questions is no", the proposal offers no *arguments* for the 
answers, it merely states a position.

For this reason, I feel the proposal is unreasonably dismissive of the aims of 
SE-0025.

Frankly, both these questions have subjective answers based on how programmers 
tend to design their programs. I personally like to build functionality using 
lots of very tiny types (many just 4 or 5 lines long), therefore, I frequently 
put multiple types in the same file (they're part of the same functionality, 
even if they're not part of the same type). However, I want to have actual 
interfaces and implementation hiding between them otherwise there's always the 
possibility of accidentally abusing the interface to each type. An access 
modifier narrower than the file, like the current scoped "private", is the 
*only* way to achieve this.

Reverting SE-0025 means the only way to have enforced interfaces between types 
is to place them in separate files. This is counterproductive for tiny types 
that form a single conceptual entity. Separate files also requires 
whole-program optimization for optimal performance.

The only conclusion I can make is that programmers in favor of this proposal 
simply don't program this way. However, I find it insulting that this proposal 
is essentially saying: your way of designing and structuring programs is wrong; 
you must use big monolithic types in their own files and endure reduced 
compilation (whole-program optimization) or runtime performance (no inlining 
between files with whole-program off).

I can't help but feel that this proposal is really misdirected frustration. 
Programmers who don't use clusters of tiny types in a single file shouldn't 
care about the existence of a scoped access modifier because it shouldn't 
affect them – they should use file access modifiers and be done. Yet 
apparently, it is file access modifier advocates pushing this proposal.

It really seems like the existence of a scoped access modifier is taking the 
blame for people's frustration that the simpler keyword ("private") is a less 
good default than the clunky keyword ("fileprivate"). I personally agree that 
the behavior or "fileprivate" is probably a better default so I understand the 
desire to give "private" back that meaning again. However, I don't want to lose 
a scoped access modifier because it is *useful* (for reasons of both project 
structure and compilation or runtime performance).

So... thumbs down from me. However, if someone wants to rename fileprivate -> 
private and rename private -> scope (or something) I'd be more supportive.

Regards,
Matt Gallagher.

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