Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Drew Crawford via swift-evolution]

First, this is an extremely well-written proposal, that explains itself well 
and tries to walk a difficult tightrope.  So, A+ for that.

That said, I think it needs modification before acceptance:

* I agree with Dave DeLong that @exhaustive does not actually "do anything", it 
relies on library authors to do the right thing but library authors cannot be 
trusted.  I am not even sure Optional will continue to have its two cases based 
on the track record of the swift-evolution process :-P
* I agree with Vladimir S that app developers need to be able to use 
compile-time checks that they handle all the "known cases" for an arbitrary 
enum (e.g. exhaustive or non-exhaustive), for example with "future" or some 
other mechanism.  Lack of testability does not actually concern me, but I feel 
it could be addressed by allowing the assignment of Any to a non-exhaustive 
enum, perhaps gated via a warning or an @testable.

I feel that a better solution to the underlying dilemma would be the following:

* As an app developer, I can use switch! or @import! to mean that I am 
vendoring this SDK and the runtime library will definitely be the same library 
I am linking against.  So it does not matter if the library author intends to 
someday add more cases – from my point of of view they are exhaustive, because 
this is the library I am linking, accept no substitutes.  Cases are checked at 
import time, and there is a runtime exception if somebody swaps the binary for 
one with "new" cases, may god have mercy on their soul
* As an app developer, in the absence of one of those opt-in mechanisms an 
imported enum is assumed to be open and I must handle either a default case 
(which is not compile-time checked for exhaustion) or a future case (which is). 
 I prefer "undefined" for "future" as a keyword because it seems to me library 
authors can also remove cases, regardless of what this proposal says.

This solution is a nod to @clattner's "the difference between source packages 
and binary packages that are updated outside your control (e.g. the OS, or a 
dynamic library that is updated independently of your app like a 3rd party 
plugin)."  But he is wrong that the difference is somehow tied together with a 
notion of binary and source: it is a difference between whether the library is 
vendored or nonvendored, that is whether it is shipped with the application or 
the OS.  If it is shipped with your application, you control the updates and so 
all enums can be exhaustive, if it is shipped with the OS it is updated 
independently and who knows what cases will appear at runtime.  But there is no 
law that says I have the sourcecode for all my application's libraries or that 
OS vendors only ship binaries, so I use "vendored" and "non-vendored", and 
"import-time" for "compile-time" to be precise in this distinction.

As a library author, I am not sure that the @exhaustive promise is meaningful.  
Unlike resilience more generally where a library author can provide some 
fallback behavior for client who calls a deprecated method, there is really not 
much that can be done to support older clients who are unaware of my new enum 
case.  I suppose we could introduce compile-time checks to prevent passing that 
enum case to an older client, for example

public enum Foo {
    case old
    @introduced (1.1) case new
}

public final enum Fixed {
    case one
    @introduced (1.1) case two //error: Can't add a new case to a final enum, 
drop @introduced or drop final
}

public func bar() -> Foo {
    return .new //error: Not all clients support case new, use if #available or 
@available
}

This sort of thing might be a justification for supporting a "final" or 
"exhaustive" declaration, but the motivation in this listing is to support 
library authors within their own compilation unit, rather than exposing a 
signal to app developers that may or may not be reliable moving forward.

As shown in this listing, I find "final" more natural and more in the spirit of 
Swift than @exhaustive.

Drew



On December 19, 2017 at 4:58:14 PM, Ted Kremenek (kreme...@apple.com) wrote:

The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
January 3, 2018.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
Reviews are an important part of the Swift evolution process. All review 
feedback 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/0192-non-exhaustive-enums.md
...
Reply text
...
Other replies
What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

[Drew Crawford via swift-evolution]

> How so? It seems that encapsulation is orthogonal to reference/value 
> semantics.

Consider this type

public struct Mailbox {
    private var _messages: [String]
    public mutating func append(message: String) { _messages.append(message)}
    public var messages: [String] { return _messages}
    public var sortedMessages: [String] { return _messages.sorted() }
}

We subsequently discover in the wild that although there are a variety of 
client patterns, certain "important" clients have the particular pattern

1.  Add messages up front
2.  Use sortedMessages accessor frequently and exclusively

It would improve the important clients without harming other clients to use the 
following implementation for our type: if the sorted accessor is used before 
the unsorted one, sort the underlying storage, and then serve that until the 
type is subsequently mutated (which important clients do not do).  This 
amortizes the cost of the sort across many calls to the accessor.

Although the underlying storage is "private" and we may consider its 
sorted-arity an implementation detail of Mailbox, in fact there is no 
straightforward way to get to that implementation from this one.  When we chose 
value semantics we promised clients that our "encapsulated" values will not 
change inside a getter; mutating the "hidden" storage breaks our promise.

I would argue this "encapsulation failure" of the _messages array is actually a 
feature, and part of the draw of value types is that they provide these kinds 
of guarantees to clients, and we subvert them at our peril. In cases where that 
is not desired reference types are available.

> We want to be able to add new stored properties to structs, or change 
> existing stored properties to computed properties (and vice versa) without 
> breaking binary or source compatibility.

If CGAffineTransform, CGPoint, in_addr_t etc. are changing their members we 
have a problem.  There are probably structs where this makes more sense, but I 
can't immediately think of an example.


On November 20, 2017 at 6:16:55 PM, Slava Pestov (spes...@apple.com) wrote:



On Nov 20, 2017, at 1:58 PM, Drew Crawford via swift-evolution 
<swift-evolution@swift.org> wrote:

I'm "weak oppose" on this proposal.

The core premise here is to increase the encapsulation of a struct around its 
member variables.  But I think the purview of encapsulation is more classes 
than structs.


How so? It seems that encapsulation is orthogonal to reference/value semantics.

 e.g. a struct leaks information about the mutation of its member variables, 
even if those variables are private.

Can you explain what you mean by this?

 Structs are the obvious implementation for a named tuple (CGPoint 
CGAffineTransform UIColor etc.) where there is inherently a fixed set of 
members that are more conveniently accessed directly.  Structs and classes have 
different purposes and so the argument for consistency with classes is weak.

With regard to the BalancedPair problem, I would prefer to see a "final struct" 
or "required init”.

The real reason we want to introduce this language change is to solve some 
problems related to resilience. We want to be able to add new stored properties 
to structs, or change existing stored properties to computed properties (and 
vice versa) without breaking binary or source compatibility. Since 
non-delegating initializers expose the exact set of stored properties to the 
client module, they break the encapsulation that we need to allow this.

Slava
On November 14, 2017 at 1:31:25 PM, Ted Kremenek (kreme...@apple.com) wrote:

The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now 
and runs through November 21, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
Reviews are an important part of the Swift evolution process. All review 
feedback 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/0189-restrict-cross-module-struct-initializers.md
...
Reply text
...
Other replies
What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

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 w

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

[Drew Crawford via swift-evolution]

I'm "weak oppose" on this proposal.

The core premise here is to increase the encapsulation of a struct around its 
member variables.  But I think the purview of encapsulation is more classes 
than structs.  e.g. a struct leaks information about the mutation of its member 
variables, even if those variables are private.  Structs are the obvious 
implementation for a named tuple (CGPoint CGAffineTransform UIColor etc.) where 
there is inherently a fixed set of members that are more conveniently accessed 
directly.  Structs and classes have different purposes and so the argument for 
consistency with classes is weak.

With regard to the BalancedPair problem, I would prefer to see a "final struct" 
or "required init".
On November 14, 2017 at 1:31:25 PM, Ted Kremenek (kreme...@apple.com) wrote:

The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now 
and runs through November 21, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
Reviews are an important part of the Swift evolution process. All review 
feedback 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/0189-restrict-cross-module-struct-initializers.md
...
Reply text
...
Other replies
What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

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?

Thanks,
Ted Kremenek
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

Re: [swift-evolution] [swift-evolution-announce] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Drew Crawford via swift-evolution]

The typical case for this function in my code is the identity closure, that is

    let a: [Int?] = ...
    print(a.filterMap {$0})

filterMap is quite poor for this situation because *each* component in the term 
is inaccurate:

1.  While we are filtering in the "english sense", in Swift the word "filter" 
carries a specific meaning involving booleans.  In particular if `a` were of 
type `[Bool?]` I believe new Swift programmers would fail to predict the result
2.  This is not a map operation when used with the identity closure.  

Most of the discussion so far addresses 1 but not 2, e.g. mapSome, mapCompact 
improve dimension 1 but not dimension 2.

I support mapMaybe because from the choices so far it is the only one that 
seems to address both dimensions.

It can also be argued that the combined API itself is a mistake, e.g. that a 
distinct API for discarding optionals as from mapping would be superior.  But 
that may be too radical at this point.

On November 15, 2017 at 2:55:10 PM, John McCall (rjmcc...@apple.com) wrote:

Hello, Swift Community!

The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" ran through 
yesterday, November 14th, 2017.  The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md

There was a significant amount of discussion, and people came down with 
reasonable arguments both for and against the proposal.  After reviewing that 
feedback, the core team feels that the central question is whether Swift 
benefits from overloading flatMap in this way.  There is a reasonable argument 
that an Optional is a sort of container, and therefore it makes sense to 
"flatten" that container into a surrounding container.  But Swift has resisted 
applying that interpretation in its library design; for example, you cannot 
directly iterate an Optional or append its contents to an Array.  In general, 
we feel that using different operations for working with Optionals tends to 
make code easier to both write and understand, especially given the existence 
of implicit optional promotion, which we cannot eliminate or easily suppress 
based on the context.  On reflection, we think it was a mistake to use the same 
name in the first place, and there is no better time to fix a mistake than now.

While we accept that this will cause some amount of "code churn" for developers 
when they adopt Swift 5, the required change is a simple rename that should be 
painless to automatically migrate.  Of course, sample code on the internet will 
become obsolete, but fix-its will easily update that code if pasted into a 
project, and the samples themselves (once corrected) should become clearer and 
easier to teach after this change, as is generally true when overloading is 
removed.

Accordingly, SE-0187 is accepted, at least as far as not calling the operation 
"flatMap".  We are re-opening the review until next Monday, November 20th, 
2017, in order to have a focused discussion about the new name.  Names that 
seemed to gain some traction in the first review include:

  - filterMap, which has precedent in existing functional languages, as well as 
some popular Swift libraries, but which some people view as confusing

  - compactMap, which builds off the precedent of "compact" in Ruby

But please feel free to suggest a name other than these.

Reviews

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 me as 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/0187-introduce-filtermap.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

As always, thank you for contributing to the evolution of Swift.

John McCall
Review Manager
___
swift-evolution-announce mailing list
swift-evolution-annou...@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Remove ownership keyword support in protocols

[Drew Crawford via swift-evolution]

+1


On September 20, 2017 at 3:11:58 PM, Ted Kremenek (kreme...@apple.com) wrote:

The review of “SE-0186: Remove ownership keyword support in protocols” begins 
now and runs through September 27.

The proposal is available here:

   
https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md

Reviews are an important part of the Swift evolution process. All review 
feedback 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/0186-remove-ownership-keyword-support-in-protocols.md
 ….
 Reply text
 ...
 Other replies

## What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

* 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?


Thanks,
Ted Kremenek
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

Re: [swift-evolution] [swift-evolution-announce] [Revised and review extended] SE-0180 - String Index Overhaul

[Drew Crawford via swift-evolution]

On June 26, 2017 at 5:43:42 PM, Karl Wagner via swift-evolution 
(swift-evolution@swift.org) wrote:

I would support a definition of encodedOffset that removed mention of UTF-16 
and phrased things in terms of String.Encoding and code-units. For example, I 
would like to be able to construct new String indices from a known index plus a 
quantity of code-units known to represent a sequence of characters:

var stringOne = “Hello,“
let stringTwo = “ world"

var idx = stringOne.endIndex
stringOne.append(contentsOf: stringTwo)
idx = String.Index(encodedOffset: idx.encodedOffset + stringTwo.codeUnits.count)
assert(idx == stringOne.endIndex)


I second this concern.  We currently use a non-Foundation library that prefers 
UTF8 encoding, I think UTF8-backed strings are important.

The choice of UTF16 as string storage in Swift makes historical sense (e.g. 
runtime interop with ObjC-backed strings) but as Swift moves forward it makes 
less sense.  We need a string system that behaves more like a lightweight 
accessor for the underlying storage (e.g. if you like your input's encoding you 
can keep it) unless you do something (like peruse a view) that requires 
promotion to a new format.  That's a different proposal, but that's the 
direction I'd like to see us head.

This proposal is in many ways the opposite of that, it specifies that we 
standardize on UTF16, and in particular we have in view the problem of file 
archiving (where we would have long-term unarchival guarantees) that complicate 
backing this out later.  This feels like a kludge to support Foundation.  In 
the archive context the offset should either be "whatever the string is" (which 
you would have to know anyway to archive/unarchive that string) or a 
full-fledged offset type that specifies the encoding such as

let i = String.Index (
    encoding: .utf16
    offset: 36
)

the latter of which would be used to port an Index between string 
representations if that's a useful feature.

More broadly though, I disagree with the motivation of the proposal, 
specifically

The result is a great deal of API surface area for apparently little gain in 
ordinary code

In ordinary code, we work with a single string representation (e.g. in Cocoa 
it's UTF16), and there is a correspondence between our UTF16 offset and our 
UTF16 string such that index lookups will succeed.  When we collapse indexes, 
we lose the information to make this correspondence, which were previously 
encoded into the typesystem.  So the "gain in ordinary code" is that 
programmers do not have to sprinkle `!` in the common case of string index 
lookups because we can infer at compile time from the type correspondence it is 
unnecessary.

Under this proposal, they will have to sprinkle the `!`, which adds friction 
and performance impact (`!` is a runtime check, and UTF16 promotions are 
expensive).  I don't believe the simplicity of implementing archival (which one 
has to only write once) is worth the hassle of complicating all string index 
lookups.

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

To me, one of Swift's greatest strengths is the type system.  We can encode 
information into the type system and find our bugs at compile time instead of 
runtime.

Here, we are proposing to partially erase a type because it's annoying to write 
code that deals with string encodings.  But our code will deal with string 
encodings somehow whether `utf16` appears in our sourcecode or not.

When we erase the type of our offset, we lose a powerful tool to prove the 
correctness of our string encodings, that is, the compiler can check our utf16 
offset is used with a utf16 string.  Without that tool, we either have to check 
that dynamically, or, worst case, there are bugs in our program.

Under this proposal we would encourage the use of a bare-integer offsets for 
string lookup.  That does not seem Swifty to me.  A Swifty solution would be to 
add a dynamically-checked type-erased String.Index alongside the existing 
statically-checked fully-typed String.UTF8/16View.Index so that the programmer 
can choose the abstraction with the performance/simplicity behavior appropriate 
for their problem.

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

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

[Drew Crawford via swift-evolution]

On April 11, 2017 at 11:38:05 AM, Joe Groff (jgr...@apple.com) wrote:

By design, Swift avoids making semantic rules based on that kind of analysis, 
since it would be brittle and difficult to describe when the compiler can and 
can't see that a condition holds nonlocally like this.
Swift *currently implements* semantic rules based on this kind of analysis.  
Exhibit A:

func foo() {

    let a: Bool

    if UUID().uuidString == "non-local condition" {

        a = true

    }

    else {

        preconditionFailure("Don't initialize a")

    }

    print("\(a)") //NOT: error: a is uninitialized

}

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

[swift-evolution] switch must be exhaustive, consider adding a default clause

[Drew Crawford via swift-evolution]

Is there a good reason we do not compile this:

import UIKit

func foo(operation: UINavigationControllerOperation) {
    switch(operation) {
    case .push: /* snip */ break
    case .pop: /* snip */ break
    default:
        preconditionFailure("This is a silly operation")
    }
    switch(operation) {
        case .push: /* snip */ break
        case .pop: /* snip */ break
         //error: Switch must be exhaustive, consider adding a default clause
    }
}
The switch *is* exhaustive, because the default case is unreachable.  The 
compiler could infer as much from branch analysis.

___
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 March 24, 2017 at 11:20:59 PM, Jonathan Hull (jh...@gbis.com) wrote:

You were the one who said redundancy was a *goal* of swift, which it is not.
You misunderstand.  I'm arguing that the design of Swift is to have concept 
pairs – private/fileprivate, class/struct, let/var – in which one element of 
the pair is a superset of the other.  That is: we could convert a let/var 
program to use only var, we could convert a private/fileprivate program to use 
only fileprivate, etc., and yet we stubbornly persist to have all these 
keywords.

This property has been labeled "redundancy" by people who dislike it.  I'm 
saying that whatever unkind name we decide to call it, it's a Swiftism, and we 
embraced it a long time ago.

Perhaps I just do not understand your argument, but it seems to be

In your examples above, Swift is projecting a system image which is much 
simpler than the underlying concepts... For access controls, the user is being 
presented with the full complexity of that choice directly.
This seems simply inaccurate to me.  For example, I am the top search result 
for "swift struct or class" and my explanation is 27 pages.  Admittedly I am an 
insufferably longwinded writer who can't find the delete key, but for whatever 
reason Google seems to think my explanation is helpful to people struggling 
with that topic.

While it is true that access control presents users the "the full complexity of 
that choice directly", this is because the choice is not actually complex.  One 
keyword is visible to a file and the other to a scope.  I could not produce 27 
pages on that topic.



___
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 March 24, 2017 at 10:28:43 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:

I'm not sure where you're reading that Chris thinks the current design reaches 
the stated aims to his satisfaction.
I'm pretty sure it's a fair assumption that when he introduces the 
static/dynamic system to illustrate the design goals of Swift, he means those 
goals can be seen in that feature to some significant extent.

"We intentionally want Swift to have a common 'center of gravity' and be an 
'opinionated' language, rather than fall to the 'design by committee' approach 
that leads to a watered-down design."  This is diametrically opposite to 
"shipping a full toolbox with plenty of overlap."
Chris has elaborated on this elsewhere:

Another thing to keep in mind is that Swift is opinionated, I guess is the way 
to say it. It really does encourage you to do the right thing where it can. For 
example, if you use var for everything, the Swift compiler [1:21:30] will say, 
hey, you marked this as a var but it could be a let, and let me fix it for you. 
That's just its subtle way of encouraging you to use immutable values, which is 
a very small thing, but it's just pushing you in the way that it thinks leads 
to a better code. Immutability for a local variable doesn't matter that much 
except that it communicates something more to the person who has to read and 
maintain your code.

I think that Swift really does [1:22:00] encourage you down the right lines in 
some ways. But on the other hand, in other places where you're saying, "Should 
something be a class or a struct?”, the trade-offs are more nuanced and it's a 
harder thing, and the Swift compiler can't just know what problem it is that 
you want to solve, so it can't help you with that.

`let` and `var` are "redundant" in the same way as private/fileprivate; one can 
effectively replace the other.  Far from advocating we should eliminate the 
redundant keyword, he argues the compiler should encourage it, because "Swift 
is an opinionated language" and an argument to the principle of least power.  
The analogous idea would be if the compiler offered a fixit to change 
"fileprivate" to "private" where legal.  Actually, that would be an interesting 
proposal, especially since some believe private/fileprivate is hard to learn.

But "Swift is an opinionated language" is not a battlecry for eliminating 
"redundant" keywords, it is an exhortation to use them correctly.

___
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 March 24, 2017 at 10:21:17 PM, Jonathan Hull (jh...@gbis.com) wrote:

This is exactly the problem. Both for access controls and dispatch.


How would you respond to clattner's position piece on this?  He disputes this 
point directly:

Swift is another case of a hybrid model: its semantics provide predictability 
between obviously static (structs, enums, and global funcs) and obviously 
dynamic (classes, protocols, and closures) constructs.  A focus of Swift (like 
Java and Javascript) is to provide an apparently simple programming model.  
However, Swift also intentionally "cheats" in its global design by mixing in a 
few tricks to make the dynamic parts of the language optimizable by a static 
compiler in many common cases...
The upshot of this is that Swift isn’t squarely in either of the static or 
dynamic camps: it aims to provide a very predictable performance model (someone 
writing a bootloader or firmware can stick to using Swift structs and have a 
simple guarantee of no dynamic overhead or runtime dependence) while also 
providing an expressive and clean high level programming model - simplifying 
learning and the common case where programmers don’t care to count cycles.
Is it?  Can you point to an instance where a member of the core team said they 
are aiming for “plenty of overlap”?

See above

Honestly, most of your examples could just be split into multiple files.
Specific arguments were advanced in those examples that they cannot.  Can you 
refute them?

You are conflating effort by the swift design and implementation community with 
your personal effort around migration.
No, I am referencing a Swift@IBM developer who reported that 

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... Accepting 
this proposal would waste hundreds of person-hours of work...
___
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 March 24, 2017 at 10:11:07 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:

I agree absolutely with those aims: very predictable performance, expressive 
and clean model, simplified learning and common cases. I'm arguing that the 
giant table of dispatch rules (see: 
http://raizlabscom-wpengine.netdna-ssl.com/dev/wp-content/uploads/sites/10/2016/12/Summary-3.png)
 does not reach that goal.
But clattner believes it does.  This is clearer in his original, which is why I 
quoted it:

predictable performance model (someone writing a bootloader or firmware can 
stick to using Swift structs and have a simple guarantee of no dynamic overhead 
or runtime dependence)
("predictable performance" to clattner means "value types are direct")

while also providing an expressive and clean high level programming model - 
simplifying learning and the common case where programmers don’t care to count 
cycles.
("simplifying the learning" to clattner means that the programming model 
appears dynamic and the real performance characteristic is hidden.)

We know (because clattner told us here) what the design goal of Swift is with 
respect to static/dynamic dispatch.  You may not agree with it, but that is 
another issue.

___
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 March 24, 2017 at 9:50:01 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:

Figuring out what's statically vs. dynamically dispatched can be very difficult 
with Swift. Although each rule is defensible when dissected individually, the 
overall scheme once `final`, `dynamic`, `@objc`, etc. are included is supremely 
inelegant. Far from being an example of a core value, I would say it's an 
example of a major weakness. I see one of the key goals of the Swift evolution 
process as reducing and, where possible, eliminating such designs from the 
language.
How would you respond to clattner's position piece on this?  It seems to 
contradict you on exactly this point, e.g.

Swift is another case of a hybrid model: its semantics provide predictability 
between obviously static (structs, enums, and global funcs) and obviously 
dynamic (classes, protocols, and closures) constructs.  A focus of Swift (like 
Java and Javascript) is to provide an apparently simple programming model.  
However, Swift also intentionally "cheats" in its global design by mixing in a 
few tricks to make the dynamic parts of the language optimizable by a static 
compiler in many common cases...
The upshot of this is that Swift isn’t squarely in either of the static or 
dynamic camps: it aims to provide a very predictable performance model (someone 
writing a bootloader or firmware can stick to using Swift structs and have a 
simple guarantee of no dynamic overhead or runtime dependence) while also 
providing an expressive and clean high level programming model - simplifying 
learning and the common case where programmers don’t care to count cycles.
___
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]

Sorry, listing should read

protocol Foo {

    func foo()

}

extension Foo {

    func foo() {}

    func bar() {}

}



On March 24, 2017 at 8:46:02 PM, Drew Crawford (d...@sealedabstract.com) wrote:

protocol Foo {

    func foo() { }

}

extension Foo {

    func bar() {}

}___
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 March 24, 2017 at 7:53:09 PM, Jonathan Hull (jh...@gbis.com) wrote:

It isn’t the fact that there are multiple models, but they way those models 
interact with each other in the brain.  You can actually have lots of different 
models without causing confusion, as long as the models fit well together.  It 
also isn’t the number of access levels that is a problem.  For example, you can 
have a ton of shirt sizes (XS, S, M, L, XL, XXL, 3XL) and it doesn’t cause more 
confusion as you add more sizes because they don’t conflict with one another.

A big part of the issue with our current access scheme is how similar the 
concepts are without being the same.  That is then made worse by the fact that 
they have been given similar names.
It is unclear what distinction you intend to draw here.  For example, value 
types and reference types are similar without being the same.  The names of 
both concepts also contain the substring "type".  So the difference you draw 
between that situation and the private/fileprivate situation is not immediately 
clear.

Note also that your list above is a list of typical stumbling blocks for new 
programmers in most languages. Swift has actually done a remarkable job with 
most of these through careful design of the way that they are framed / exposed 
to the programmer.  In general, these things are well separated from each 
other. 
I do not think Swift has done even a *good* job framing these concepts.  For 
example

protocol Foo {

    func foo() { }

}

extension Foo {

    func bar() {}

}

One of these is statically dispatched and the other one is dynamically 
dispatched.  I would guess the vast majority of Swift developers are not aware 
there's a difference at all, let alone can explain why one is slower in a 
benchmark.

Swift is good at giving programmers flexibility in their tools.  Here we have 
two superficially similar tools with slightly different features and 
performance characteristics, and for most problems it does not even matter 
which one you choose.  IMO shipping a full toolbox with plenty of overlap is 
one of the core values of Swift.

I would suggest that the practicable reason we are talking about removing 
private/fileprivate instead of protocol/extension or reference/value is that 
while `extension` etc. makes your code more powerful, `private` makes it less 
powerful.  It is not obvious to everyone why less power is desirable and so 
here we are.

Do you feel that allowing both scoped private & file-based private is actually 
important enough to warrant the significant design work it would take to bring 
it up to par with these other features? 
It is not clear to me what design work is actually outstanding.  I would love 
to see submodules, but that seems only indirectly related to visibility 
keywords, and I'm not aware of what you seem to believe we need.

I do use scoped access extensively, and I've left some examples of that 
upthread.

It is not impossible, but it really doesn’t feel worth the effort to me (say 
compared to using that time/energy/thought to check off features from the 
generics manifesto).
Rather, as Carl Brown argued, it would take a lot of time/energy to migrate 
even the official projects off of private/fileprivate.  Keeping what we have is 
free, change is what is expensive, and this proposal is change.

 In general, Swift is an opinionated language
Not clear what you mean here either.  Swift is clearly less opinionated than 
ObjC for example.  I am having trouble connecting this claim to a practical 
application.

___
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 March 24, 2017 at 11:46:00 AM, Charles Srstka (cocoa...@charlessoft.com) 
wrote:

On Mar 24, 2017, at 11:41 AM, Drew Crawford via swift-evolution 
<swift-evolution@swift.org> wrote:

I would argue that supporting whatever the programmer's chosen mental model is 
actually Swift's greatest strength.  We could have a language with only 
reference types for example, it would be far, far simpler and easier to teach.  
I am glad that we don't have that language.

We kinda do, though, or did, in Objective-C (well, the “Objective” parts of it, 
anyway).

Charles


Exactly.  I mean the same people who brought us ObjC decided we needed a 
language with multiple mental models.  They could have shipped reference types 
only, they shipped value types on day 1.  To me there is no clearer plank in 
the platform than that.

If you like your ObjC, you can keep it.  Swift exists exactly because we reject 
some (not all) of the ObjC way, and it's not just syntax.  One of the things 
rejected is There Should Be One Way To Do It™.  Swift embraces many ways to 
write your program and has from 1.0.___
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]

There are a couple of problems with the design which are causing Cognitive 
Dissonance:

1) Private & fileprivate require very different mental models to operate them
2) They are named very similarly to each other
3) There is a third concept of “private to the type” which requires a third 
mental model, but is spelled the same way in other languages 

How would you respond to the allegation that supporting different "redundant" 
semantic models is actually a *design goal* of Swift?  For example:
Value semantics vs reference semantics
Pass-by-owned vs pass-by-shared vs pass-by-reference parameters
dynamic dispatch vs static dispatch
associatedtype vs generics
"complete" types (e.g. Array) vs  "incomplete" types (Sequence) and which 
one is permitted after a colon
strong vs weak vs unowned
I would argue that supporting whatever the programmer's chosen mental model is 
actually Swift's greatest strength.  We could have a language with only 
reference types for example, it would be far, far simpler and easier to teach.  
I am glad that we don't have that language.  I don't use all of these in every 
program, but I use all of them eventually, and each one is right for some 
situation.

Many of us don't know half these models half as as well as we'd like.  But we 
also like less than half of them half as well as they deserve.  Visibility is 
in line with the trend here.

Of the three, I am personally most supportive of file-based


My concern about dropping down to file-based is it doesn't allow any nesting, 
which isn't powerful enough for several examples posted in this discussion.  
Unless by "file-based" we mean "directory-based" which is another proposal that 
has seen strong opposition from the "it's too complicated" wing.


On March 24, 2017 at 5:00:33 AM, Jonathan Hull via swift-evolution 
(swift-evolution@swift.org) wrote:


Several people have asked:  What is the harm it causes?

I would like to provide a (hopefully) clear answer to that.

There are a couple of problems with the design which are causing Cognitive 
Dissonance:

1) Private & fileprivate require very different mental models to operate them
2) They are named very similarly to each other
3) There is a third concept of “private to the type” which requires a third 
mental model, but is spelled the same way in other languages 

Any one of these would cause confusion.  All of them together mean that even 
those of us who understand how they work are bothered by them on a subconscious 
level (similar to how misaligned graphics will give everyone a subconscious 
feeling that a graphic design is “off” even if they can’t discern why 
consciously).  Even many of those who are arguing to keep private have argued 
to rename things or to make it work in a more type-based way by extending 
visibility to extensions.  I don’t think anyone is denying there is a problem 
here with the status quo.

There is a general rule in design that things that look similar (or in this 
case are named similarly) need to behave similarly to avoid causing confusion 
(and conversely things that behave differently *need* to look different).

**This is not something that will go away simply by learning the behavior.  It 
will continue to be a rough spot in the language that causes discomfort until 
the underlying design issue is fixed.**

The ideal solution here would be to choose a single model and make everything 
coherent under that.  We choose either file-based, scope-based, or type-based 
access control and unify under that.

For file-based, that means that our sub-modules, when we add them, would need 
to be file-based as well.

If we choose Scope-based, then it really cries out for some sort of 
parameterized private.  That is you only have private and public, but for 
private you would be able to name a scope to widen the visibility to the named 
scope.  Submodules would then need to be scope based, and you would probably 
use the parameterized private with the submodule name to share data within it.

Type-based is very common in other languages, but I fear it would not play 
nicely with the way Swift has grown to work.  The pros are that you could 
access private variables from extensions, but getting types to work together 
with the ease they do now would require a lot of design work (and may not even 
be quite possible).  You also have additional complexities around subtypes, 
etc...


We really need to choose a single direction and not mix and match.

Of the three, I am personally most supportive of file-based because it is the 
closest to where we are now, and it seems to simplify many of the concerns 
about “friend” types by having visibility be dependent on proximity… which 
seems very intuitive to me.

As I said before, my preference would be to tentatively accept the change, but 
delay implementation until we design submodules for Swift 5. That way the 
design can be more cohesive as we can tackle it all at once.  If submodules 
won’t be in scope until after 

Re: [swift-evolution] Pitch: Partial Implementations

[Drew Crawford via swift-evolution]

I agree with all of this, and I lack strong feelings about whether this should 
be restricted to the same compilation unit or allowed in multiple compilation 
units.

On March 23, 2017 at 1:12:51 PM, Charles Srstka via swift-evolution 
(swift-evolution@swift.org) 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 24, 2017 at 10:17:57 AM, Matt Whiteside (mwhiteside@gmail.com) 
wrote:

In other words, this use case seems fairly distant from what was intended for 
private vs fileprivate.
The "not public API" motivation is directly in view for private/fileprivate.  
Promoting this API to a module would make it API public to our customers.

___
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

[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] [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

[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] [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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

It has been expressed in various ways "does anybody actually use scoped 
visibility in the wild" and "what real benefit does it provide to production 
code".

The below file or some estranged stepchild of it appears at least 5 
repositories (that I know of; this is practically a samizdat around here).  The 
scoped access modifier is a significant improvement to the safety of this code 
and by extension the many projects that contain it.

Apologies if this listing is rather tiring.  Many of the "solutions" proposed 
by the anti-private camp sound great in a sentence but fall apart at scale.  
But it is not obvious why this is so to people who do not use the keyword, so I 
can understand why they keep suggesting poor solutions.  Perhaps with a more 
involved listing, it will become more obvious why many of these suggestions do 
not work.  The original is a lot longer; I did reduce it to only the parts that 
seem relevant to this thread.

import Foundation

/**
 This code demonstrates one of the usecases for 'private'.  Adapted from real 
production code, this file exports a threading primitive to the rest of the 
program.
 
 To state it briefly, private is necessary here because we need the following 
visibility nesting to achieve our objective:
 
 ┌───┐
 │PROGRAM/internal                           │
 │                                           │
 │                                           │
 │     ┌───┐ │
 │     │ ThreadsafeWrapperNotifyChanged    │ │
 │     │                                   │ │
 │     │      ┌──┐     │ │
 │     │      │   ThreadsafeWrapper  │     │ │
 │     │      │                      │     │ │
 │     │      │                      │     │ │
 │     │      │          value       │     │ │
 │     │      │                      │     │ │
 │     │      │                      │     │ │
 │     │      └──┘     │ │
 │     │                                   │ │
 │     └───┘ │
 └───┘
 
 In particular:
 
 1.  value a.k.a. "t" must be protected against all potential unsafe access.  
This file is hundreds of lines, auditing the whole thing is very tedious.
 2.  ThreadsafeWrapper is an implementation detail of 
ThreadsafeWrapperNotifyChanged which is not intended for use by other callers.  
To avoid exposing the class to other callers, it must appear in this file.
 3.  This file cannot be made an entire module, because it's actually used as 
part of several projects that are shipped as frameworks, and apparently some 
developers get really annoyed when they have to drag too many frameworks into 
their Xcode project.
 4.  The use of `private` here reduces the "maybe not threadsafe" part of the 
code from 196 lines to 47 lines (a reduction of buggy code of 76%).  In the 
production file from which this example is derived, the reduction is from 423 
lines to 33 lines, or 92%.  A scoped access variable significantly improves the 
threadsafety of this code.

 */

//Define an interface common to both major components
private protocol Threadsafe : class {
    ///the type of the value we are protecting
    associatedtype T
    ///Access the underlying value.
    ///- parameter block: The block that will be passed the protected value.  
The block acts as an exclusive lock; while you're in it, no other consumers 
will be accessing the value.  
    ///- complexity: Coalescing multiple operations into a single block 
improves performance.
    func accessT(_ block: @escaping (T) throws -> K) throws -> K
    ///Mutate the underlying value.
    ///- parameter block: The block that will be passed the protected value.  
The block acts as an exclusive lock; while you're in it, no other consumers 
will be accessing the value.
    ///- complexity: Coalescing multiple operations into a single block 
improves performance.
    func mutateT(_ block: @escaping (inout T) throws -> K) throws -> K
}

///Some convenience accessors for callers that do not need a block-based API to 
get lock semantics / operation coalescing
extension Threadsafe {
    var value : T {
        get {
            var t: T! = nil
            try! accessT({ lt in
                t = lt
            })
            return t
        }
        set {
            try! mutateT({ (lt:inout T) -> () in
                lt = newValue
            })
        }
    }
}

///The core synchronization primitive.  This is a private implementation detail 
of ThreadsafeWrapperNotifyChanged.
//MARK: audit this area begin
private final class ThreadsafeWrapper : Threadsafe {
    /**The value we are protecting.  This value needs to be protected against 
unsafe access from
    1.  This type, if a scoped keyword is available (as shown)
    2.  The entire file, if a scoped keyword is removed.
     Only access this value on the synchronizationQueue.
     */
    private var t: T
    ///The queue that 

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

[Drew Crawford via swift-evolution]

On March 21, 2017 at 9:18:00 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:

You're not hearing the argument. No one "accidentally" included this design as 
part of SE-0025; it's sentence number one. 
To quote this in context:

Scoped access level allows hiding implementation details of a class or a class 
extension at the class/extension level, instead of a file. It is a concise 
expression of the intent that a particular part of a class or extension 
definition is there only to implement a public API for other classes or 
extensions and must not be used directly anywhere outside of the scope of the 
class or the extension.

I can see how an adversarial reading of the first sentence would argue that 
implementation details are not actually hidden by your example (which is, for 
the record, technically correct, the best kind of correct :-).  However, the 
second sentence clarifies which kind of implementation details we mean to hide 
– the accidental use of members outside the scope.

Your example does not involve hiding in that sense, so while it is interesting, 
and a bug, and should be fixed, etc., it does not thwart the practicable goal 
of the proposal.

And no one just "forgot" to make the code above work; it simply can't be 
accommodated by the current mangling scheme. 
The Swift mangling scheme changes with some frequency, I know of around 3 revs 
offhand and I do not work in that area often.  So holding this up as an 
immovable object is odd.

Things would be different if we declared a stable ABI, but we did not, etc.

And--what's more--_no one seems to be bothered by it_.
I volunteer to be bothered by it.  Where’s my cookie?___
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 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution 
(swift-evolution@swift.org) wrote:

Swift should only impose a preference when it's important to the speed, 
functionality, and safety of the language. I have yet to be convinced that 
there's a benefit to a scoped access level that fits anywhere in there.
SE-0025 addresses these *specific* points.

speed & safety:

> Also, there is a greater danger of using private APIs if they do something 
> similar to public APIs but are somehow more optimized (because they make 
> additional assumptions about the internal state).
functionality:

> It forces a one class per file structure, which is very limiting. Putting 
> related APIs and/or related implementations in the same file helps ensure 
> consistency and reduces the time to find a particular API or implementation. 
> This does not mean that the classes in the same file need to share otherwise 
> hidden APIs, but there is no way to express such sharability with the current 
> access levels.



I have spent entire weeks of class trying to extoll the benefits, so 
breathlessly shared on these mailing lists, of how beautiful it is to have a 
scoped access level. I have yet to succeed.
Perhaps this suggests scoped access modifiers are more comparable to e.g. 
“owned” in the Memory Management Manifesto or UnsafeRawPointer/SE-0107.  Those 
features are breathtakingly difficult to teach, with design documents in the 
dozens of pages that are so dense I do not understand them.

However, they solve hairy problems down in the dungeon somewhere, and most 
programmers do not actually need to know them to write their code.

I don’t think scoped is quite to that level, but even if it were: if you like 
your visibility modifiers you can keep them!  There is no law that says you 
must use all the modifiers, and the availability of a feature does not “impose 
on all of us the personal code style preferences” of anyone.  Removing a 
feature does, and that’s the present proposal.

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

ents of new `private` disagree on one of two key goals stated 
for new `private`;

I suspect that not everyone will agree on the three stated goals for extensions 
either, but I do not with to remove them.  I wish to improve them, and a scoped 
access modifier is one of the tools we have to do that.

As far as I can see, in that example, you can rename `private func prune` to 
`private func _prune` and have no further problems. That is to say, the 
workaround is a single character at each use site, which by your metric makes 
this proposal half as onerous as removing `++`.
The problems are described in SE-0025:

> Another, less reliable, way is to prefix APIs that are meant to be hidden 
> with a _ or do something similar. That works, but it’s not enforced by the 
> compiler, and those APIs show up in tools like code completion, so the 
> programmer has to filter out the noise — although these tools could quite 
> easily support hiding methods with the _ prefix standard. Also, there is a 
> greater danger of using private APIs if they do something similar to public 
> APIs but are somehow more optimized (because they make additional assumptions 
> about the internal state).
In any case, this workaround is not “semantically equivalent” and so regardless 
of the number of characters it is different than ++ or var.



On March 21, 2017 at 5:26:47 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:
On Tue, Mar 21, 2017 at 3:59 PM, Drew Crawford via swift-evolution 
<swift-evolution@swift.org> wrote:
 The arguments for the revert are in the proposal and in the discussions in 
this thread.

What is in the proposal and this thread are a set of opinions, e.g.

* "the access level change of SE-0025 was met with dissatisfaction by a 
substantial proportion of the general Swift community."
* "Those changes can be viewed as actively harmful,”
* "it is extremely common to use several extensions within a file.”
* “[existing regime] encourages overuse of scoped access control”
* “[fileprivate is the] more reasonable default”

I am asking for the arguments or evidence that led you or others to these 
opinions.  I understand that you and others believe them, but you understand 
that they are now a matter of debate. We are not going to reach any mutual 
understanding just asserting things we believe.  The underlying evidence is 
what would be necessary to convince others to our point of view.  I am trying 
to ascertain what that evidence is.

> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, 

The context here is that you presented an argument that Swift’s “private” was 
confusing to users of other languages:

> In most languages, that keyword is “private” so its valid to say that 
> newcomers to the language will “default” to using that one. 

If you no longer think that argument is strong because it relies on a 
comparison to other languages, then we agree :-)  But in that case we lose an 
argument for this proposal.  The reason we are talking about other languages is 
because that was an argument advanced to support the proposal.


I am confused by this response. An argument in _support_ of new `private` was 
that it is more in line with expectations of users coming from other languages. 
In other some cases, such an argument might have its place. However, as others 
have pointed out on this list, those other languages don't have facilities like 
Swift's extensions, and therefore it was not a very strong argument for new 
`private` to say that it better aligns with user expectations coming from other 
languages.
 
> Some people used the for(;;) loop, the ++ operator, var parameters.

In those cases, there was extensive discussion of how to achieve the things 
people were achieving with those features with alternative patterns. var 
parameters for example have a 1LOC workaround to achieve the previous 
semantics, ++ had two characters, for(;;) was slightly trickier but we had a 
clear concept of the scope of the impact. So far as I’m aware, the only 
suggestion to people who currently use a scoped access modifier is to stop 
having their problems.

You've given one example of code that takes advantage of new `private`. As far 
as I can see, in that example, you can rename `private func prune` to `private 
func _prune` and have no further problems. That is to say, the workaround is a 
single character at each use site, which by your metric makes this proposal 
half as onerous as removing `++`.

So the circumstances of earlier removals and this one are very different.

> • either a programmer ... will use private as often as possible
> • or a programmer will … use fileprivate all the time 
There is also the possibility that a programmer considers which modifier is 
appropriate for the code they are writing.  You "argue that... is very rare” 
but I still am not sure what this argument is or wha

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

[Drew Crawford via swift-evolution]

 too much detail in 
the proposal because I think this debate is purely a question of philosophy on 
Swift and its language features. I did not want to add un-necessary bloat that 
would have added little rationalisation. Let me try to explain the holes in the 
proposal by answering your review:

On 21 Mar 2017, at 02:26, Drew Crawford via swift-evolution 
<swift-evolution@swift.org> wrote:

I disagree quite strongly with the proposal.

First, the document draws conclusions without apparent supporting evidence, e.g.

> Since the release of Swift 3, the access level change of SE–0025 was met with 
> dissatisfaction by a substantial proportion of the general Swift community. 
> Those changes can be viewed as actively harmful, the new requirement for 
> syntax/API changes.
What is “dissatisfaction by a substantial proportion of the general Swift 
community”? How was this measured/determined?
It’s not feasible to measure precisely the feeling of a whole community. But we 
get a feeling for it by following the mailing-list, by talking to colleagues, 
by reading twitter, etc… And it think we all agree that the debate is highly 
divisive and that a “substantial proportion” of the community was dissatisfied: 
I’m not arguing that it is less or more than a majority. I’m just saying that 
we’ve seen a lot of talk against the original change.
What was done to control for the population happy with SE-0025 who would e.g. 
not be likely to take up pitchforks?
That’s why its important we have this debate now.
Who argues these changes are “actively harmful” and where were they during 
SE-0025?
The proposal makes the argument that the changes are actively harmful. It’s now 
up to debate. By the way, even if several people (including me) were already 
against this proposal during the review, I don’t see why anybody would not have 
the right to change his mind, especially after several months of production 
usage and argue differently now.
> subtly encourages overuse of scoped access control and discourages the more 
> reasonable default
Who claims that scoped access is “overused” and what is their argument for 
doing so?
Why is “fileprivate” the “more reasonable default”? In fact neither fileprivate 
*nor* private are default (reasonable or not!). Internal is the default. Nor 
does this proposal suggest we change that. So this seems a very strange 
statement.
By default, I did not mean the syntactic default of the language but the access 
modifier users will use “by default” when trying to restrict visibility. In 
most languages, that keyword is “private” so its valid to say that newcomers to 
the language will “default” to using that one. If the proposal is accepted, 
file-scoped private will regain that status.
> But is that distinction between private and fileprivate actively used by the 
> larger community of Swift developers?
Yes. To cite some evidence, here are codebases I actively maintain:

| codebase                                               | private # | 
fileprivate # | ratio |

||---|---|---|

| "M" (proprietary)                                      | 486       | 249      
     | 2x    |

| "N"(proprietary)                                       | 179       | 59       
     | 3x    |

| NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15        | 1        
     | 15x   |

| atbuild https://github.com/AnarchyTools/atbuild        | 54        | 5        
     | 11x   |

So from my chair, not only is the distinction useful, but scoped access control 
(private) is overwhelmingly (2-15x) more useful than fileprivate.

My own statistics in my projects show the contrary. At best, this shows how 
divisive this feature is. During the discussion of this proposal, it was argued 
that making decisions based upon project statistics would be dangerous:

In old code, statistics could be biased by the migrator having replaced all 
previous instances of private by fileprivate.
In new code, satistics could be biased by people using private because of it 
being the “soft-default”, regardless of proper semantics.
> And if it were used pervasively, would it be worth the cognitive load and 
>complexity of keeping two very similar access levels in the language? This 
>proposal argues that answer to both questions is no

This proposal does not make any later argument about “cognitive load” or 
“complexity” I can identify.  Did the proposal get truncated?

Sorry if I did not state it explicitly, but I see any feature/keyword added to 
the language as “additional complexity”. And that complexity is completely 
worth it when the feature adds significant expressivity. I'm just arguing that 
the additional scope-based access modifier does not provide enough 
differentiation to be worth that complexity.
What is stated (without evidence) is that "it is extremely common to use 
several extens

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

[Drew Crawford via swift-evolution]

True indeed… but can we agree that this is just an hypothetic example, and no 
issue that is likely to happen in productive code?
Or is this actually taken from one of the projects you measured?
Here is the expanded edition which is productive.

/**A dummy return value to indicate a method isn't threadsafe.
 Because unused return values produce warnings in Swift, a caller who uses the 
method absentmindedly will have a warning in their code.  This can be 
suppressed with `let _: NotThreadSafe` from the caller. */
struct NotThreadSafe { }

///There are many cache implementations with different performance 
characteristics.
///we model them with a protocol.
protocol CacheImplementation {
    func prune() -> NotThreadSafe
}

///Many components share a single cache, so we expose it as a reference type
class Cache {
    
    init() { preconditionFailure("Provide a constructor to satisfy the 
compiler") }
    private var v: CacheImplementation
    private let lock = DispatchQueue(label: "lock")
    
    
    private func prune() -> NotThreadSafe {
        v.prune()
        return NotThreadSafe()
    }
    ///expose a threadsafe API to callers
    internal func prune() {
        lock.sync {
            //supress the warning, since we have a lock.
            let _: NotThreadSafe = self.prune()
        }
    }
}

extension Cache {
    func pruneAgressively() {
        for _ in 0..<5 {
            self.prune()
        }
    }
}

Note that, in this example, the scoped access keyword actually makes extensions 
*easier*, not harder, to write, because the extension does not need to choose 
between a safe and unsafe version of the method.

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

t want to add un-necessary bloat that 
would have added little rationalisation. Let me try to explain the holes in the 
proposal by answering your review:

On 21 Mar 2017, at 02:26, Drew Crawford via swift-evolution 
<swift-evolution@swift.org> wrote:

I disagree quite strongly with the proposal.

First, the document draws conclusions without apparent supporting evidence, e.g.

> Since the release of Swift 3, the access level change of SE–0025 was met with 
> dissatisfaction by a substantial proportion of the general Swift community. 
> Those changes can be viewed as actively harmful, the new requirement for 
> syntax/API changes.
What is “dissatisfaction by a substantial proportion of the general Swift 
community”? How was this measured/determined?
It’s not feasible to measure precisely the feeling of a whole community. But we 
get a feeling for it by following the mailing-list, by talking to colleagues, 
by reading twitter, etc… And it think we all agree that the debate is highly 
divisive and that a “substantial proportion” of the community was dissatisfied: 
I’m not arguing that it is less or more than a majority. I’m just saying that 
we’ve seen a lot of talk against the original change.
What was done to control for the population happy with SE-0025 who would e.g. 
not be likely to take up pitchforks?
That’s why its important we have this debate now.
Who argues these changes are “actively harmful” and where were they during 
SE-0025?
The proposal makes the argument that the changes are actively harmful. It’s now 
up to debate. By the way, even if several people (including me) were already 
against this proposal during the review, I don’t see why anybody would not have 
the right to change his mind, especially after several months of production 
usage and argue differently now.
> subtly encourages overuse of scoped access control and discourages the more 
> reasonable default
Who claims that scoped access is “overused” and what is their argument for 
doing so?
Why is “fileprivate” the “more reasonable default”? In fact neither fileprivate 
*nor* private are default (reasonable or not!). Internal is the default. Nor 
does this proposal suggest we change that. So this seems a very strange 
statement.
By default, I did not mean the syntactic default of the language but the access 
modifier users will use “by default” when trying to restrict visibility. In 
most languages, that keyword is “private” so its valid to say that newcomers to 
the language will “default” to using that one. If the proposal is accepted, 
file-scoped private will regain that status.
> But is that distinction between private and fileprivate actively used by the 
> larger community of Swift developers?
Yes. To cite some evidence, here are codebases I actively maintain:

| codebase                                               | private # | 
fileprivate # | ratio |

||---|---|---|

| "M" (proprietary)                                      | 486       | 249      
     | 2x    |

| "N"(proprietary)                                       | 179       | 59       
     | 3x    |

| NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15        | 1        
     | 15x   |

| atbuild https://github.com/AnarchyTools/atbuild        | 54        | 5        
     | 11x   |

So from my chair, not only is the distinction useful, but scoped access control 
(private) is overwhelmingly (2-15x) more useful than fileprivate.

My own statistics in my projects show the contrary. At best, this shows how 
divisive this feature is. During the discussion of this proposal, it was argued 
that making decisions based upon project statistics would be dangerous:

In old code, statistics could be biased by the migrator having replaced all 
previous instances of private by fileprivate.
In new code, satistics could be biased by people using private because of it 
being the “soft-default”, regardless of proper semantics.
> And if it were used pervasively, would it be worth the cognitive load and 
>complexity of keeping two very similar access levels in the language? This 
>proposal argues that answer to both questions is no

This proposal does not make any later argument about “cognitive load” or 
“complexity” I can identify.  Did the proposal get truncated?

Sorry if I did not state it explicitly, but I see any feature/keyword added to 
the language as “additional complexity”. And that complexity is completely 
worth it when the feature adds significant expressivity. I'm just arguing that 
the additional scope-based access modifier does not provide enough 
differentiation to be worth that complexity.
What is stated (without evidence) is that "it is extremely common to use 
several extensions within a file” and that use of “private” is annoying in that 
case.  I now extend the above table

| codebase                 

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

[Drew Crawford via swift-evolution]

On March 21, 2017 at 7:00:32 AM, Tino Heth (2...@gmx.de) wrote:

> If private is really more useful, should we remove fileprivate instead?
We don’t have to remove any access modifier.  They are all useful.

> Fact is, you can replace every occurrence of "private" with "fileprivate", 
> and your source would compile as before, whereas fileprivate saves us from a 
> "friend"-keyword.
This is certainly a source-breaking change.  Consider:

struct Foo {

    fileprivate func foo()->String {return "foo" }

    private func foo()->Int {return 2}   

}

print("\(Foo().foo())")

Replacing “private” with “fileprivate” here will introduce a compile error.





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

Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

[Drew Crawford via swift-evolution]

Thanks for using specific examples, as they are illustrative.

Or, as used in 
https://github.com/drewcrawford/Caroline/blob/edd8aefef44717ecfa03c629100baf095fab983a/caroline-static-tool/main.swift
 to just get access to the exit() function, which is the same across all 
platforms.

exit is an interesting case.  Believe it or not, it is *not* portable, as used 
here.  The C standard defines two constants for its parameter: EXIT_SUCCESS 
(defined to be zero) and EXIT_FAILURE (undefined).  You can pass other values 
(trivia time: only values less than 0377, because the high bits of this integer 
are reserved on some platforms), but the "fail-iarity" or "successiness" of 
values other than the defined two are not specified and may take on different 
meanings on different platforms.  C programmers commonly pick a nonzero value 
to indicate failure (as I did here) – sometimes multiple distinct values to 
indicate different kinds of failure – but this is actually non-portable.

The reason I am being pedantic here is because it demonstrates a broader point: 
people do not actually write portable code; they target either their current 
platform or some vague amalgamation of  2-3 platforms in their immediate 
vicinity.  All the platforms I cared about do something sane with exit(1) so 
it's "portable enough".  But "portable enough" isn't portable.

 In any case, the four lines at the top of your files are almost certainly 
inconsistent on other platforms; for example, do you test for freebsd? Or ps4?

This is a feature, not a bug.  We *like* compiler errors because they give us 
early warning we got something wrong.

I *want* the compiler to stop me when compiling this for OpenVMS.  When I wrote 
this code, I had only Darwin/Glibc in mind, and on that basis, I used exit(1). 
The working assumption is now violated, and the compiler is correct to remind 
me about it.  I don't know, and would need to go find out, what kind of exit is 
sensible for VMS.  Or to move to EXIT_FAILURE like a language lawyer.

But the compile error itself is not a silly annoyance that I would like to 
"solve" by blindly putting more libcs in the list etc. This is a guard rail 
where I indicated the platforms I had in mind when writing this code, and when 
I wake up one morning in a drunken stupor and try to do something else, we fire 
a warning shot.

It's a safety feature, like force-unwrap.  If you're sure it won't blow up, you 
can put an exclamation mark in there and shut up the compiler.  If you're sure 
it's portable to bsd, add bsd to the list and shut up the compiler.  But the 
resolution to this compile error is not to import more libcs.  The resolution 
is to *consider carefully if that is a good idea*.

The assumption embedded in the proposal is that of course we want the program 
to compile, and the question is merely to calculate the set of import 
statements that will achieve compilation, for which the proposal offers an 
algorithm.  My argument is that actually we do not want the program to compile 
unless we are reasonably sure it will work as intended, and the question is 
what syntax allows the author to reasonably encode their assumptions so that 
when they are violated we provide a moment of quiet reflection to consider e.g. 
if exit(1) is sensible on VMS.

The existing system is imperfect (and very ugly) but does a surprisingly good 
job in this dimension.

 It also doesn't seem to support some of the other platforms that might be 
desirable in a test framework, such as iOS, watchOS or tvOS.
I do support iOS (not in this component – it's a command-line tool, so the 
omission of iOS in this file is deliberate, and the compatibility issues go far 
beyond exit).  I don't yet support watchOS or tvOS because I don't have CI for 
those platforms yet and in my view supporting a platform is more than adjusting 
an import statement and wondering if it will compile.

So in summary:

1.  I would not use this feature in the cited examples

2.  I would prefer it if others did not use this feature.  When I see "import 
Glibc" at the top of a file I know what I am signing up for.  When I see 
"import libc" for all I know the developer used Windows.

Finally, this is more of a detail, but I still do not understand how this would 
be implemented for a Linux platform without Glibc, such as Arch.  The current 
proposal has 



  #if os(Linux)

      @_exported import Glibc

which is obviously not going to compile on Arch.  So if the goal is to have 
syntax that is portable the current proposal does not do it.

I do believe there is some room for a more moderate reform on the libc problem. 
 For example instead of the traditional ifdefs, we could have

import? Glibc

import? Darwin


Where the "import?" keyword imports the module if available or otherwise has no 
effect.

This preserves the majority of desireable properties discussed above (clearly 
indicates the intended libcs, provides guard rails similar to the present 
regime) while 

Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

[Drew Crawford via swift-evolution]

grep -R "import Glibc" ~/Code --include "*.swift" | wc -l
297

As someone who might be characterized as suffering from the problem this
proposal purports to solve, I am not convinced.

The primary problem here is that "libc" is a misnomer.  Did you mean
musl, dietlibc, or glibc?  Did you mean "whatever libc my distro likes?"
Swift in practice only supports one per platform, but that is a bug not
a feature, and that bug should not be standardized.  We could try to
invent some syntax to specify one but now we are back with the current
system again.

The other problem is that in all my usages, "import Glibc" is not a real
problem I face.  The real problems are that "the libcs *plural*" are
*just different*.  Darwin has timeval64, glibc does not, and you'd
better check your arch and pick the right one, only on one platform.
SO_REUSEADDR has one type in Brand X and another type in Brand Y.  Don't
even get me *started* on poll, EREs, or half a dozen other behavioral
variations.

Taking two different libraries and pretending they are the same is not
the solution, it's the disease.  The way out of this swamp for most
developers is to use a real Swift library, the same damn Swift library,
on all platforms (sadly, Foundation today does not meet this
requirement).  The way out of this swamp for crazy people like me who
must write to the metal is to actually write to the metal, to the
particular libc being targeted, not to a hypothetical platonic ideal
libc which does not exist.

I realize that four lines at the top of my files is a *visible*
annoyance, but fixing it just promotes it to an invisible one.

Drew

--
  Drew Crawford
  d...@sealedabstract.com



On Wed, Nov 9, 2016, at 12:58 PM, Alex Blewitt via swift-evolution wrote:
> Although out of scope for phase 1, something that keeps cropping up in
> a variety of Linux/Darwin Swift scripts is the conditional inclusion
> of Darwin or GlibC per platform. The last point was an observation
> that creating a 'nice' wrapper for LibC or a cleaned up POSIX API is a
> non-goal:
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027621.html
>
>> I think it makes sense to have a cross platform “libc” which is an
>> alias for darwin, glibc, or whatever, and just leave it at that.
>> Other proposals for a “POSIX” module have gotten bogged down because
>> inevitably the idea comes up to make the resultant API nicer in
>> various ways: rename creat, handle errno more nicely, make use of
>> multiple return values, … etc.  The problem with this approach is
>> that we don’t *want* people using these layer of APIs, we want higher
>> level Foundation-like APIs to be used.  ...*
* I think we should formally decide that a “nice” wrapper for libc is a
  non-goal.  There is too much that doesn’t make sense to wrap at this
  level - the only Swift code that should be using this is the
  implementation of higher level API, and such extremely narrow cases
  that we can live with them having to handle the problems of dealing
  with the raw APIs directly.  -Chris
>
> I have created a draft for a proposal to create such a module.
> Comments are welcome.
>
> Alex
>
> ---
>
> # Libc module for Swift
>
> * Proposal: [SE-](-filename.md)
> * Authors: [Alex Blewitt](https://github.com/alblue)
> * Review Manager: TBD
> * Status: **Under discussion**
>
> ## Introduction
>
> When running on Darwin, the base module is called `Darwin`.
> When running
> on Linux or other operating systems, it's called `GlibC`.
>
> This repeatedly leads to code such as:
>
> 
> #if os(Linux)
>   import Glibc
> #else
>   import Darwin
> #endif
> ```
>
> As the set of operating systems evolve, one of these
> conditional imports
> needs to be updated. Instead of repeating this, make it
> available via a
> standard `Libc` module in the base Swift library.
>
> Swift-evolution thread: [Discussion thread topic for that proposal]
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027621.html)
>
> ## Motivation
>
> The [set of platforms]
> (https://github.com/apple/swift/blob/fdf6ee20e4ca1fd32482f4b7b88a97ebdda52cd2/lib/Basic/LangOptions.cpp#L26-L36)
> that Swift currently runs on can be divided into two; Darwin and XNU
> based systems
> (macOS, iOS, watchOS, tvOS), Windows, and Unix based systems
> (Linux, FreeBSD, Android, PS4).
>
> The base module on Darwin is called `Darwin`, while on Linux and
> other Unix systems the base module is called `Glibc`. The base
> module is typically conditionally included when working at a
> lower layer
> than Foundation (which has the same detail involved in importing the
> base module).
>
> As a result, conditionally importing the right version typically uses
> a conditional test based on the operating system, and the same code is
> seen in a number of different modules, both internal to Swift and
> external:
>
> * [Test for mmap in stdlib]
>   
> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

[Drew Crawford via swift-evolution]

I think this is already part of the Generics Manifesto: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

So is this proposal.  The proposal's "Motivation" is lifted from the Arbitrary 
Requirements in Protocols section: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#arbitrary-requirements-in-protocols-


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

Re: [swift-evolution] SE-0138 UnsafeBytes

[Drew Crawford via swift-evolution]

On September 2, 2016 at 2:36:43 AM, Andrew Trick (atr...@apple.com) wrote:

After thinking about this for a moment, I like the approach of extending 
UnsafeBytes with release-mode bounds checked versions of subscript, load, and 
storeBytes.
I agree with this, I think it's mostly a question of naming and defaults.  My 
concern here is letting a swift developer accidentally write heartbleed, which 
we can't actually prevent, but we can make it harder.

IMO 

1.  There should be clear consistency in the checked-ness of the API surface.  
Agree that checked iterator makes no sense, but I think the most important 
thing is to avoid creating a job interview trivia game where `set` is checked 
but `store` is unchecked, spot the bug in this function.

2.  For consistency with UnsafeBufferPointer it may make the most sense to just 
ship unchecked or ship an opt-in checked wrapper.  I believe however that the 
existing precedent is all wrong on this point, and I'd like to see us revisit 
this question across both interfaces in Swift 4, but I don't want to lay out a 
whole case here that should be its own thread.

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

Re: [swift-evolution] SE-0138 UnsafeBytes

[Drew Crawford via swift-evolution]

Proposal link:
 

I'm possibly one of the larger users of raw byte stuff in Swift as I maintain 
an entire client/server network protocol stack in Swift userspace, similar in 
spirit to one of the examples drawn out a lot longer.  Grepping my code 
produces over 200 individual uses of unsafe byte accesses.

I definitely agree that the problem is significant enough to warrant a 
last-minute change.

To a first approximation I agree with all the implementation choices.  The 
naming, the choice of UInt8, length tracking, and debug-bounds checking are all 
correct IMO.  We have been using something similar for a long time internally 
[have you been reading my code? :-) ] so I can speak from experience that the 
basic plan here is sound.

One thing I would like to see is an (opt-in) release-mode-bounds-check.  
Networking is a core use case for this feature, but when you are reading from a 
socket, production is where you need a guard against out-of-bounds UB the most. 
 If we can't solve it for Swift 3, affected users can write a wrapper to 
implement the boundscheck, but I think we should at very least take it up again 
for Swift 4.

Drew


On September 1, 2016 at 5:19:02 PM, Andrew Trick via swift-evolution 
(swift-evolution@swift.org) wrote:

I’m resending this for Review Manager Dave A. because the announce list is 
dropping his messages...

Hello Swift community,

The review of "UnsafeBytes" begins now and runs through September
7th. This late addition to Swift 3 is a follow-up to SE-0107:
UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer,
allowing developers to continue working with collections of UInt8 values,
but now doing so via a type safe API. The UnsafeBytes API will not require 
direct manipulation of raw pointers or reasoning about binding memory.

The proposal is available here:

 


Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

 

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:
 

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

 

Thank you,

-Dave Abrahams
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] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Drew Crawford via swift-evolution]

> On May 11, 2016, at 6:34 AM, David Hart  wrote:
> 
> It sounds extreme to me to release a v1 of a library without giving yourself 
> the flexibility to iterate on it beforehand.

Dispatch is already released (on two platforms).  So that ship sailed in 2010.  
The question in front of us is whether we're going to focus in getting the 
Linux port to parity with Darwin or whether we're going off an an API design 
adventure before seriously addressing that goal.

It seems prudent to point out that "API design" appears last on our list of 
Swift 3 goals, while "Portability " 
is in the top three.  So I don't know why my position would be "extreme", as it 
is more consistent with what we are on paper supposed to be doing in this 
release.

It also seems prudent to point out that we are going to do the first preview 
branch tomorrow.  Obviously none of us really know what to expect, but the 
official guidance includes such statements as "only changes that align with the 
core goals of the release will be considered" and "Source-breaking changes to 
the language will be considered on a case-by-case basis."  I think we should 
consider whether rewriting the entire Dispatch API surface area is something 
that would clear that bar.

I agree with all the individual API changes.  They're great.  I just think the 
timing is wrong.  We should get to Darwin parity, and then we'll be in a 
position to pull the trigger on this.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Drew Crawford via swift-evolution]

I'm one of the largest dispatch-on-linux users right now.  In fact, I'm 
reasonably sure I'm THE largest.  I have an application in production that uses 
some 400 dispatch calls.  

On Linux, I'm running Swift 3 in production, essentially because Dispatch/Linux 
in 2.2 does not even exist.  On OSX/iOS, I compile the same codebase with Swift 
2.2, because that's the version that's released, and using released software is 
a sane thing to do.

This proposal places me in the uncomfortable situation of trying to somehow 
smooth out a truly MASSIVE API delta with #if.  And that's not going to happen. 
 Realistically, what I will do is create some kind of FrankenSwift that either 
backports the new API to Swift 3 or the old API to Swift 2.  And that is a ton 
of work, really stupid work, and I would infinitely prefer to spend that time 
doing something actually useful to the world.  To be clear, I don't fear 
migration; what I fear is the heisenmigration, where one of my platforms must 
migrate, and the other ones can't.

More broadly, I am concerned about the direction the language is going where we 
do not even have working libraries yet and already we are doing sweeping API 
changes to them.  I suspect this is motivated by a fundamentally incorrect 
premise–the premise that because it's not released yet, we can get away with 
it.  When actually that's backwards: we can get away with breaking changes 
later, but if we do them now we will ruin everything.  Let me explain.

Right now, Linux Swift programmers exist. And they need to be able to solve 
ordinary problems, like writing a string to a file, or spinning up a background 
thread.  And I do mean: sometime before Late 2016.  No amount of telling them 
"don't do that, it's not released" is going to stop this.  The only question is 
whether upstream is going to be the repo that solves their problem, or whether 
they go to solve the problem somewhere else.  Because when they go somewhere 
else, they invest there.

Increasingly, because upstream is not interested in the problem, I am seeing 
Linux folk go solve the problem somewhere else.  Just counting the projects I'm 
personally aware of, there are 3 foundation alternatives and 1 package manager 
alternative.  All because upstream has no sane path to e.g. reading a file on 
disk in the kind of timeframe working programmers actually need to do it in.

What we *should* be doing is creating libraries that *work*, *releasing them*, 
and then we can do as much API Disneyland as we want without harassing the 
working programmer.

1.  If we're out of bugs to fix, why not release?  Then folks like me can get 
off the snapshot treadmill and we won't be annoyed by massive API delta until 
we can do it all at once, which is (relatively) easy.
2.  If we're not out of bugs to fix, why not work on them, and then release, 
and then come back to this?
3.  Since Swift 3 will have a stable ABI, why not ship both libdispatch2 and 
libdispatch3 and let the programmer plan her own migration?  I'm not even sure 
the stable ABI part is relevant, since Dispatch is almost entirely C.

All of these are saner alternatives to the proposal, and all of them achieve 
the stated goal (e.g. we still end up with happy modern APIs).

I don't mean to pick on this proposal specifically, I agree with the need to 
modernize the API surface area.  But if we continue to do breaking changes 
first and releases later I'm concerned about where the early adopters will get 
pushed to.

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

Re: [swift-evolution] String(validatingUTF8:) doesn't

[Drew Crawford via swift-evolution]

CChar is typedefed to Int8 I believe.  So the CChar=>Int8 implicit conversion 
is not surprising.

The conversion from an [Int8] to an UnsafePointer is a bit of a sharper 
edge, although there are cases where it makes sense (e.g. calling to C).  
Importing C APIs with some kind of decl to opt into array-pointer conversion 
may make more sense than what we do now.

But independently of the language-level design problem, this is a bad API.  Its 
name does not describe what it does, It causes UB even though the word "unsafe" 
does not appear anywhere as is our convention, and quite frankly I don't 
understand why it is so important to have an API to work with CStrings when we 
could have an API to work with arrays in the standard library instead.  

I thought there might be a performance reason, but having read the sourcecode 
it looks O(N), so I am at a loss as to what problem this solves that an 
array-based API does not, that justifies the sharp edge of memory-unsafety.

Drew

> On Apr 21, 2016, at 5:23 AM, Vladimir.S <sva...@gmail.com> wrote:
> 
> How at all Swift allows such an implicit conversion from one type to another, 
> at the same time when we must explicitly convert let say Int8 to Int16 ???
> 
> I.e. this is not allowed
> 
> var i8 : Int8 = 10
> var i16 : Int16 = i8
> 
> But [Int8] to UnsafePointer - no problems.
> 
> It is very weird behavior in this case.
> 
> Anyone can explain why String(validatingUTF8:) should silently convert [Int8] 
> to UnsafePointer ??
> 
> On 21.04.2016 12:01, Drew Crawford via swift-evolution wrote:
>> I have just now for the second time root-caused yet another "nasty nasty UB
>> bug" from yet another developer who got cut on the very sharp edge of this 
>> API:
>> 
>>var result = [40,50,60] as [Int8]
>>return String(validatingUTF8: result)
>> 
>> This poorly-named String constructor does not take a Swift array of UTF8
>> bytes, it takes an UnsafePointer to a C string.  When that C string is not
>> null-terminated (as shown here), UB ensues.
>> 
>> I believe **at least** we need a sane name for this constructor like
>> String(validatingUTF8CString:) that vaguely suggests what the programmer
>> can do to avoid UB.
>> 
>> I further believe that this API is just plain bad, but swift-dev disagrees
>> and so in the interests of doing /something/ to stop the bleeding I propose
>> we rename.
>> 
>> Drew
>> 
>> 
>> ___
>> 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] SE-0031 and Swift 2

[Drew Crawford via swift-evolution]

Hello,

I'm writing to complain about SE-0031 and Swift 2 compatibility.  I understand 
(and agree with!) the change, but the migration between now and 2017 is 
annoying, hence my complaint.

In snapshot swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a, we started erroring on the 
old syntax.  That means that this:

func foo(inout bar: Int) { }

is not legal Swift 3.

...however, the new syntax:

func foo(bar: inout Int) { }

is not legal Swift 2.  This complicates compiling for both, which several of my 
projects currently do.

/Further complicating matters/, Swift does not understand line-scoped ifdefs.  
So this:

#if swift(>=3.0)
func foo(bar: inout Int) {
#else
func foo(inout bar: Int) {
#endif
//my
//long
//functon
//definition
}

Is not legal Swift.  The only way I know of is to say:

#if swift(>=3.0)
func foo(bar: inout Int) {
//my
//long
//functon
//definition
}
#else
func foo(inout bar: Int) {
//my
//long
//functon
//definition
}
#endif

which forces duplication of the entire function definition.

My suggestion would be one or more of the following:

1.  Support both syntaxes in Swift 3 "trunk" (e.g. until Swift 3 is released).
2.  Backport the new syntax to Swift 2.2
3.  Consider allowing line-scoped ifdefs

Thanks for reading, and sorry to rain on a parade I largely think is Good For 
Swift ™

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

Re: [swift-evolution] deployment targets and frameworks

[Drew Crawford via swift-evolution]

> On Apr 6, 2016, at 1:35 PM, Douglas Gregor  > wrote:
> 
> Fortunately, Swift tells you when you get it wrong.

It doesn't, though.  That's the thing.

Consider CloudKit, first available in iOS 8.  Does that framework's 
implementation rely on new, novel APIs only available on iOS 8, and the Swift 
compiler threw availability errors to the implementor of CloudKit?  Or, is the 
reason the reason it's "unavailable" in 7 because Apple decided as a point of 
business not to compile, test, and QA an iOS 7.3 that added CloudKit?  Well I 
don't have the sourcecode so I don't know, maybe there is some incredibly novel 
API involved in talking to computers on the internet not available in iOS 7.  
But I suspect it's mostly a business decision, not technical.

So, if we assume that's the case (or, if I'm wrong, replace CK with a framework 
for which there is no technical reason why it's unavailable), then Apple paid 
some QA engineer to sprinkle @available on all the public APIs.  Meanwhile, 
third-party developers in this situation are similarly making business 
decisions not to support iOS 7/8, and we also have to grab our QA engineer and 
comb through the API very carefully.

I'm suggesting is we can all fire the QA engineer with a compiler feature.

> Really, this syntax is a shorthand for “treat the imported library as if the 
> author had put this availability annotation on all of its public APIs”.

What if we solve the problem at "framework-compile-time" rather than at 
"import-time"?

Suppose we have some driver flag that injects @availability onto every decl in 
the module.  For decls with existing @availability it simply raises the floor 
to some minimum value.  Now we distribute the module, and the availabilities 
have been set.

My intuition would be to use the existing "deployment target" flag to control 
this feature, since this is how framework authors actually do express their 
intent to support an OS.  But if we need to introduce a novel concept of an 
"availability target", that's fine too.

The important thing is that it's zero-effort for consumers of the framework, 
and I get to fire my QA engineer.

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

Re: [swift-evolution] deployment targets and frameworks

[Drew Crawford via swift-evolution]

> On Apr 5, 2016, at 12:06 PM, Douglas Gregor  wrote:
> 
> I would not want this to be implicit behavior: it should be recorded in the 
> source with, e.g.,
> 
>   @availability(iOS: 9.3) import YourCustomFramework
> 
> so that it is clear that the imported declarations are only available on iOS 
> 9.3 or newer.
> 
>   - Doug

Would you promote using this syntax for the Apple frameworks as well?

A major goal for me is syntax consistency between Apple's and third-party 
frameworks.  That way the knowledge of how to use one transfers to the other, 
and we ensure people with fresh ideas about how to build frameworks are not 
burdened with educating application developers about "novel" import syntax.

>From consulting the table 
>,
> developers with a DT of 7.0 (which is the oldest Swift supports) would need 
>to add e.g. @availability(iOS 8.0, *) import CloudKit for a few frameworks, 
>but that seems like a pretty easy change.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] deployment targets and frameworks

[Drew Crawford via swift-evolution]

> On Apr 4, 2016, at 7:01 PM, Jonathan Tang  wrote:
> 
> I assume that the @available annotation generated would also work for 
> watchOS, tvOS, etc. frameworks.

Yes

> How would it work for non-iOS Swift platforms?  I'm not terribly familiar 
> with how #available works on Linux, but the versioning problem exists there 
> too.

In my experience, "linux" cannot be listed inside @available.  I think we need 
to add it.

I'm not sure the "version" of Linux is meaningful (e.g. - interpreted as kernel 
version? glibc?) but I think clearly "linux" the vaguely-versioned platform 
should be allowed in an @availability attribute.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] deployment targets and frameworks

[Drew Crawford via swift-evolution]

Suppose *Apple* ships a framework that is only supported in iOS 9.3.  As a 
direct consequence, the framework is only #available in iOS 9.3 or later.

Suppose Jane links this framework into her iOS application.  The deployment 
target for her application *can be any value*.  She sets the framework to be 
weakly linked, and as long as the code that uses the Apple framework is guarded 
by a 9.3 availability check, she can deploy back to 8.0, 7.0, etc.

Suppose *I* ship a custom framework that I only want to bother supporting for 
iOS 9.3 users.  I'm not testing on old OS, I don't have CI on old OS, and quite 
frankly I have no idea if it works.  And I'm not in the habit of shipping code 
that wasn't even tested on my machine.  As a direct consequence, I set my 
framework deployment target to 9.3.

Now Jane links this framework into her "deployment target 8.0" application.  
She weakly links it and uses availability checks just like she did with the 
Apple framework.  But this time the compiler says no:

error: module file's minimum deployment target is ios9.3 v9.3

Jane now has a set of bad choices:

1.  She can not use my framework at all
2.  She can drop support for <9.3 entirely from her application in order to use 
my framework
3.  She can convince me to support iOS 8, when I don't want to invest in the QA 
and test time.
4.  She can convince me to set my deployment target to 8, try to find all my 
public APIs, sprinkle `@available(iOS 9.3, *)` everywhere and hope I didn't 
miss any.  Spoiler alert: that's what I did all afternoon.

This is too hard.  IMO Jane should be able to use my "9.3+" frameworks as 
easily as she can use Apple's.

IMO, when Jane imports a "DT 9.3" framework, into her "DT 8.0" application, it 
should A) import successfully, B) link weakly, and C) have `@availability(9.3, 
*)` overlayed on the interface.

There may be some subtle additional details because I don't know exactly the 
implementation of these features, but that's the general idea.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

[Drew Crawford via swift-evolution]

The swift package manager is currently considering its own define 
<https://github.com/apple/swift-package-manager/pull/105#issuecomment-168754567>,
 so it's now the second official project that could benefit from this syntax.

David, any interest in writing this up?

> On Jan 3, 2016, at 4:48 AM, Goffredo Marocchi <pana...@gmail.com> wrote:
> 
> +1 from me as well, supporting conditional compilation when the two versions 
> of foundation differ and may differ for the foreseeable future seems a must 
> on this end.
> 
> Sent from my iPhone
> 
> On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>>> If we are going to support something like this, I’d rather see it be 
>>> something everyone could leverage as there are many use cases for this 
>>> feature:
>>> 
>>> #if available("package-name", "1.2.*")
>>> #endif
>> 
>> Big +1.
>> 
>> I've asked specifically to get some kind of conditional compilation on 
>> corelibs-foundation 
>> <https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20151228/000287.html>
>>  being used.  corelibs-founcation is currently incompatible with Darwin 
>> Foundation, and so it is impractical to make a single codebase build for 
>> both.
>> 
>> But building the same application against both Foundations and spotting 
>> differences is one of the important ways we're going to spot bugs.
>> 
>> So I think the code quality of Foundation ultimately hinges on getting some 
>> feature like this in the language.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <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] Separate protocols and interfaces

[Drew Crawford via swift-evolution]

I offer a +1, but I have two criticisms of the proposal.

The first is that the example given in the proposal is stated a lot more 
strongly than is true:

> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>   if first < second {
> return -1
>   }
>   //...
> }
> The code above yields an error, and rightfully so, because if the real types 
> of first and second are not equal, they cannot actually be compared.
> 
It is true for Swift 2 code.  However, whether this is true forever is less 
clear.  There is a thread here discussing "existential protocols", which AFAIK 
would make this code listing into a non-error, and in that thread Douglas 
Gregor said:

> Do recall that I’m saying “not now” rather than “not ever” for this feature. 
> I think it’s very, very cool, but it’s complicated and we need a while to 
> understand its overall effects.

As long as the door is open to allowing the syntax, I think saying something 
strong and normative about it in an official proposal would be a mistake.  The 
example is fine, but the comment should be that this "currently errors" or 
"surprises new programmers" or something weaker than "it's obvious to all of us 
this shouldn't work" because it's obvious to some people that it should work 
after all.

The second thing is that I think using the words "dynamically dispatched" or 
"dynamically dispatched interfaces" in the body of the proposal is a mistake.  
It is not that interfaces "are" dynamically dispatched.  It is that they may 
be, e.g. that the compiler may select a dynamic implementation (or it may be 
able to find a static implementation), whereas for a protocol the compiler is 
guaranteed to use a static implementation.  This is I think more consistent 
with CL's position on static/dynamic in Swift 

 generally.  So I think we should find a turn of phrase like "behaves 
dynamically" or "has dynamic dispatch semantics" rather than saying "it *is* 
dynamically dispatched" as if we will force the optimizer to spit out a vtable 
when it can find a static implementation.

With those two details resolved I think it is a strong proposal, and very much 
in line with the proposal we're reviewing about separating typealias vs 
associatedtype, which strikes at a similar confusion where we're separating two 
different concepts into their own keywords.


> On Jan 3, 2016, at 7:44 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> +1 to "opening" values of existential type, I remember trying (and failing) 
> to do this when Swift 1 came out. Being able to capture the dynamic type of 
> an object at runtime and do stuff with it would be incredible.
> 
> Austin
> 
> On Sun, Jan 3, 2016 at 4:19 PM, David Waite via swift-evolution 
> > wrote:
> This would be wonderful - is it something that could happen in the Swift 3 
> timeframe? Is it something that myself or someone else could work on a formal 
> proposal for?
> 
> -DW
> 
>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>>> > wrote:
>>> 
>>> Introduction of interfaces will clean up the current blend of static and 
>>> dynamic protocols, and solve at least three popular issues.
>>> Please see:
>>> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>>>  
>>> 
>> I am *completely* against this proposal.
>> 
>> Fundamentally, you're trying to address the limitation that protocols with 
>> Self or associated type requirements can't be existential. But it's just a 
>> limitation that isn't (conceptually) that hard to fix: the primary operation 
>> you need to work with an existing of such a protocol is to "open" a value of 
>> existential type, giving a name to the dynamic type it stores. Let's invent 
>> one:
>> 
>>   func eq(x: Equatable, y: Equatable) -> Bool {
>> // give the name T to the dynamic type stored in xT
>> let xT = open x as T
>> // is y also storing a T?
>> guard let yT = y as? T else { return false }
>> // check whether the Ts are equal
>> return xT == yT
>>   }
>> 
>> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
>> thing back to something more "static", just by giving a name to the type. 
>> Swift generics aren't really even static in any sense: what the do is give 
>> names to the types of values so one can establish relationships among 
>> different values. "open..as" would do that for existentials. 
>> 
>> Note that ether Swift compilers AST and SIL both have "open existential" 
>> operations 

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Drew Crawford via swift-evolution]

> Existentials for protocols with Self and / or associated type requirements 
> would require bindings for Self and / or the associated type(s).  At least 
> when you use a member that contains Self and / or an associated type in its 
> signature.  So the previous example will always fail to compile. 

Not true.  Joe Groff:

> This seems like it would be addressed just by allowing Factory to be used as 
> a dynamic type, with its Product type generalized to Any. We'll be set up to 
> support that with some runtime work to store associated types in protocol 
> witness tables (which is also necessary to fix cyclic conformances, one of 
> our Swift 3 goals).


> Yeah, when generalizing a protocol type, we ought to be able to either 
> generalize the associated types to their upper bounds, for use cases like 
> yours, or constrain them to specific types, for the AnyGenerator kind of 
> case.




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

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

[Drew Crawford via swift-evolution]

> If we are going to support something like this, I’d rather see it be 
> something everyone could leverage as there are many use cases for this 
> feature:
> 
> #if available("package-name", "1.2.*")
> #endif

Big +1.

I've asked specifically to get some kind of conditional compilation on 
corelibs-foundation 

 being used.  corelibs-founcation is currently incompatible with Darwin 
Foundation, and so it is impractical to make a single codebase build for both.

But building the same application against both Foundations and spotting 
differences is one of the important ways we're going to spot bugs.

So I think the code quality of Foundation ultimately hinges on getting some 
feature like this in the language.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Drew Crawford via swift-evolution]

Thanks for directing me to this, I missed it.

> Most projects will not conform to these conventions.

Giggle.  Kind of an understatement, no?

Like, okay.  Here is a project I'd like to package.  (Read: I do package it, 
with features not in mainline swiftPM.)  https://github.com/jedisct1/libsodium 


Let's take a look at how this package realistically builds:

* It has tests ("make check")
* It has various --enable-foo flags
* It swaps in special implementations depending on if you have AMD64 

 or AVX instructions 

 or SSE2 

 etc.
* The optimization level is tuned on a per-architecture basis 

* They build (also) on Windows.  They're not changing how they're packaged for 
"SwiftPM, the Mac/Linux build system".
* Oh and this is cryptography code.  Do you *really* want to touch it?

I think an important feature of any C target proposal is that there will 
actually exist C targets which can be built under the proposal.  Until there 
are C people coming out of the woodwork saying "sure, I will repackage my 
software this way" I think the entire value is debatable.

Getting signoff from libdispatch/CoreFoundation is necessary but not sufficient 
to clear that hurdle.  I would think getting the other C deps in our own 
project family to repackage would be "table stakes" for any new C build system. 
 The real test are projects that are third-party and less friendly.

And I do not see realistically how we are ever going to support a project like 
libsodium, except calling out to automake.  An automake solution coincidentally 
supports both libdispatch and CoreFoundation right now.  IMO something like 
that is a much, much better direction in the short-term, and once we have done 
the first step of "packaging" those software via automake we will have "real" C 
projects in our package manager and we can design our C support around the 
concerns of real projects instead of imaginary ones.

> On Jan 2, 2016, at 11:00 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:
>  
> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
> 
> Some TL;DR:
> - The proposal defines a basic convention for pure C language targets (no 
> Swift/C mix and match, but other Swift targets can use the C targets).
> - This is just intended to be the minimal initial feature, there will be a 
> lot of add on work which I expect should be tackled in follow on 
> PRs/proposals.
> - The proposal doesn't try and outline every single nitty detail (e.g., 
> exactly what C++ standard we will compile with). My intention is to pick a 
> sensible default at implementation time and refine incrementally.
> 
> Unless there are serious objections, I am hoping to hope to land this 
> proposal soon and start work on the feature shortly after.
> 
> Cheers,
> - Daniel
> 
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

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

Re: [swift-evolution] Proposal for Package Manager Testing Infrastruture

[Drew Crawford via swift-evolution]

I'm wondering what the next steps for this proposal are.

I see Max's comment from the 16th 
 
advising to pull back discussion to the list, but I haven't seen any further 
discussion in the past 10 days.  Does someone feel that there are outstanding 
problems to address?  Even if there is some further discussion we need to have, 
IMO it would be appropriate to have that discussion in the context of a 
swift-evolution review.

I personally back the proposal essentially in its entirety.  I think it is 
vague on some points we will want to take up as separate proposals, but I don't 
think they are worth holding up the ability to test packages at all, which is 
the present situation.

I am not familiar with what exactly the criteria is for that PR to be accepted 
into swift-evolution and begin a review, which IIRC is the next stage in the 
process.  I do notice that it is the second oldest of the 12 open PRs in the 
queue.




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

Re: [swift-evolution] Final by default for classes and methods

[Drew Crawford via swift-evolution]

> On Dec 22, 2015, at 11:03 AM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> I’m not totally opposed to final by default. Joe’s arguments sway me in 
> principle. In practice, if Swift does indeed moves us toward “less wiggle 
> room, less hackable” by default, then that wiggle room _will_ have to come 
> from somewhere else: perhaps more open sourcing and more forking, or faster 
> turnaround on fixes from library authors, or a larger portion of time spent 
> by library authors explicitly exposing and documenting customization points. 
> The new effort involved for library authors is nothing to sneeze at.

> On Dec 21, 2015, at 11:50 AM, Jordan Rose via swift-evolution 
> > wrote:

> Of course Apple code will have bugs in it. Trying to patch over these bugs in 
> your own code is (1) obviously not an answer Apple would support, but also 
> (2) fraught with peril, and (3) likely to break in the next OS release.
> 
> TLDR: It's already unsafe to do this with the existing set of Swift features. 
> Yes, this makes things "worse", but it's not something we're interested in 
> supporting anyway.

I actually agree with making final default.  But I think it's important to 
understand the consequence.  "One does not simply" seal all the classes.

I'm going to repeat publicly something that third-party developers (including 
me) have been talking about privately for over a year.  We're going to end up 
moving to open-source, community-maintained frameworks (a la 
swift-corelibs-foundation), and away from closed-source Apple-maintained 
dependencies.

This isn't the place to rehash the whole tired history of it, but to provide a 
little context: I alone have 217 open, non-duplicated radars under my main 
account.  That is a lot of radars.  The problem resolution strategies available 
to third-party developers are very very bad.  Subclassing is one of those "bad" 
resolution strategies that everybody agrees is awful, but what are you going to 
do, rewrite the core Apple frameworks by yourself?

Yes, as it turns out.  Many of us were pleasantly surprised (and some of us 
literally could not believe) Apple's support for this effort with 
swift-corelibs-foundation.  But I think (some) on this list may be unprepared 
for the full extent to which the community will be taking on an active role.  I 
actually have a whole queue of patches in the basement that predate 
swift-corelibs-foundation completely that I will be sending upstream slowly, 
and what gets rejected will be third-partied somewhere.  That's before we even 
get to the question of replacing some of the other technologies that don't 
appear on github.com/apple .  

IMO making the transition to "open" frameworks that we can actually 
fork/fix/bundle ourselves is the Right Solution™ to this whole "final" debate, 
but I think it is important to preview for everybody involved that this is the 
straw on a very overworked camel.  I had to subclass UIKit yet again just a few 
days ago.  Paul Cantrell is 100% right that the wiggle room will have to come 
from somewhere. 

The wiggle room will come from the community stepping up and making our own 
tools.  That has been happening to some extent in the dark, but presently it 
will be happening in the daylight.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution