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

[Colin Barrett via swift-evolution]

> On Dec 20, 2017, at 1:36 PM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> Thanks for the links, Colin. I think neither of these approaches are 
> appropriate for Swift, largely for the same reason: they can't be used to 
> define a library's API. Polymorphic variants are ad-hoc union types (much 
> like tuples are ad-hoc structs) which—apart from having other problems in 
> Swift previously discussed on this list—means that you can't add new cases to 
> them. That is, any API which takes `(red(r: Int) | green(g: Int) | blue(b: 
> Int))` today can't add `alpha(a: Int)` in the future, because that would 
> change the type.
 
It would change the type yes, but not in a binary incompatible way. Imagine 
this for the OS version, using OCaml pseudocode

type VERS = [> `10_0 | `10_1 | … | `10_13 ]

Then, next year, you’d change VERS to be,

type VERS = [> `10_0 | `10_1 | … | `10_13 | `10_14 ]

Any code that dealt with a VERS would still work, as it had to handle that it 
could contain other tags.

> ML-style exceptions have the opposite problem; they are completely 
> unconstrained and so a client can add new "cases" without the library author 
> being prepared. (Swift's error-handling model in general behaves a lot like 
> this, except it doesn't get ML's knowledge of which errors might be thrown.)

Yes, I was imagining that this would be for something with an OCaml type like 
[> ]  or TOP, which I don’t believe is a thing? My OCaml-fu is quite weak.

> I'd sum this up by saying Swift is differing from ML and from most other 
> languages because it is solving a different problem. Swift is designed such 
> that the compiler does not require whole-program knowledge to produce a 
> correct, working, type-safe program. It will use any cross-module knowledge 
> it can for optimization purposes, but the language semantics do not depend on 
> it. And this is critical, as you note, for libraries with binary 
> compatibility concerns.

That is… not different from ML? ML’s modules have precisely this properly, do 
they not? Or am I misunderstanding what you’re saying here.

> Jordan

Thanks for the reply, it’s appreciated! Hope you’re well in California, envious 
of your weather trudging thru the snow here in NYC.

-Colin

> 
> 
>> On Dec 20, 2017, at 10:13, Colin Barrett via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I very much agree with the motivations for this proposal. It identifies a 
>> clear, urgent need.
>> 
>> I disagree that the proposed solution is a good solution. It makes a very 
>> significant, and confusing, change to the language that does not have much 
>> precedent in other languages. This goes against the stated design guidelines 
>> for the Swift language.
>> 
>> I would much rather see Swift follow the lead of other ML languages and 
>> introduce something like “polymorphic variants”[1] or Standard ML’s 
>> exceptions (which are "open” in this way by default)
>> 
>> Thanks for everyone's hard work, particularly the authors,
>> -Colin
>> 
>> [1]: 
>> https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants 
>> <https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants>
>> [2]: https://www.cs.cmu.edu/~rwh/introsml/core/exceptions.htm 
>> <https://www.cs.cmu.edu/~rwh/introsml/core/exceptions.htm> 
>> 
>>> On Dec 19, 2017, at 5:58 PM, Ted Kremenek via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>>>  
>>> <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 
>>> <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
>>>  
>>> <https://g

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Colin Barrett via swift-evolution]

This would be easily solved if pattern matching was available as an expression, 
such as in Haskell, OCaml / Standard ML, and Scala / Kotlin. :-)

> On Dec 20, 2017, at 11:44 AM, Ethan Diamond via swift-evolution 
>  wrote:
> 
> Hello everyone,
> 
> One major pain point I've run into with Swift is the inability to evaluate 
> the case of an enum that has associated values in a way that just returns a 
> bool. We've been given the ability in a switch statement:
> 
> enum Enum {
>case a(param: String)
>case b(param: String)
> }
> 
> let enumeration: Enum = a(param: "Hi")
> switch enumeration {
> case a:
>   // Do something
> case b:
>   // Do something
> }
> 
> We'e been given the ability in the context of an if statement:
> 
> enum Enum {
>case a(param: String)
>case b(param: String)
> }
> 
> let enumeration: Enum = a(param: "Hi")
> 
> if case .a = enumeration { 
> // Do something
> }
> 
> But without a basic was of getting a bool for if an enum is a given case, 
> here's a list of things I can't do:
> 
> Where statements:
> 
> enum Enum {
>case a(param: Enum2)
>case b(param: Enum2)
> }
> 
> enum Enum2 {
> case c(param: String)
> case d(param: String)
> }
> 
> let enumeration: Enum = a(param: "Hi")
> switch enumeration {
> case a(let inner) where [INNER CASE IS .c]
> }
> 
> -
> 
> Filter an array for a certain case:
> 
> Expertly explained by Erica Sadun here: 
> http://ericasadun.com/2017/01/31/challenge-filtering-associated-value-enumeration-arrays/
>  
> 
> 
> -
> 
> Nicely set a UIButton to hidden if an enum is a certain case:
> 
> enum State {
> case `default`
> case searching(results: [Result])
> }
> 
> myButton.isHidden = [STATE IS .searching]
> 
> -
> 
> I've run into this issue a ton of times because I tend to represent my views 
> a State enums. I haven't seen anything on the board for plans for solving 
> this issue, thought. Has there been any discussion about addressing it? 
> Ideally I'd be able to do this:
> 
> enum Enum {
>case a(param: String)
>case b(param: String)
> }
> 
> let enumeration: Enum = a(param: "Hi")
> 
> case .a = enumeration // Bool
> case .a(let param) = enumeration // Bool, assigns "Hi" to "param"
> 
> Thanks!
> Ethan
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Colin Barrett via swift-evolution]

I very much agree with the motivations for this proposal. It identifies a 
clear, urgent need.

I disagree that the proposed solution is a good solution. It makes a very 
significant, and confusing, change to the language that does not have much 
precedent in other languages. This goes against the stated design guidelines 
for the Swift language.

I would much rather see Swift follow the lead of other ML languages and 
introduce something like “polymorphic variants”[1] or Standard ML’s exceptions 
(which are "open” in this way by default)

Thanks for everyone's hard work, particularly the authors,
-Colin

[1]: https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants 

[2]: https://www.cs.cmu.edu/~rwh/introsml/core/exceptions.htm 
 

> On Dec 19, 2017, at 5:58 PM, Ted Kremenek via swift-evolution 
>  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, 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 mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

[Colin Barrett via swift-evolution]

Most of the proposal looks fine to me. A welcome feature. Eager to see
anyone's ideas for further extension to the range DSL—perhaps this will
spark people's imaginations
http://matt.might.net/articles/parsing-with-derivatives/

My only comment is concern over leaving out ..< It's not the prettiest
operator, true, but in the name of consistency and the "principle of least
surprise" I think it's the right one to use. I'm trying to imagine
explaining this to someone learning Swift—"... means up to and including
(except when it doesn't.)" Sounds like a mini-nightmare to me.

Cheers,
-Colin

On Tue, Apr 18, 2017 at 12:40 AM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Colin Barrett via swift-evolution]

Proposal Link:
https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md

I'm a +1 on the proposal, I just have a few small questions and suggestions
after giving it a brief read.

1) I'm not thrilled about the name "unkeyedContainer()" and related names.
Would "sequentialContainer" or something along those lines be a better
name? The fact that it can encode several, heterogeneous values in a fixed
sequence seems to be the most salient feature of it that distinguishes it
from the keyed containers and the single value containers.

2) I feel like the reasoning behind the design for the CodingUserInfoKey
isn't clearly articulated, but it seems a bit odd to me. First off, I'm
confused why with the current design, the declaration isn't simply:

protocol CodingUserInfoKey: CodingKey, Hashable {}

I tried mocking something up with the shipping Swift 3.1, and got the
following error:

> using 'CodingUserInfoKey' as a concrete type conforming to protocol
'Hashable' is not supported

So maybe it's just a question of lack of compiler support. Still, I feel
that the lack of a connection between the CodingKey and the
CodingUserInfoKey types is fairly confusing.

To be more concrete but way more speculative, I'm assuming that current
design one is intended to declare all their keys in an enum like,

enum SomeType.Key: CodingKey {
  case foo
  case bar
  // ...
  case metaKey1
  case metaKey2
}

And then write an init? extension for CodingUserInfoKey.

It seems more natural however to me to leverage the nested container
support instead. What exactly that design would look like is unclear to
me—do you return a value that implements Encoder? Do you add duplicate
nestedKeyedEncoder for the userInfo case? but it seems more of a clean fit
with the rest of the API than exposing a dictionary.

Both pretty minor issues when considered with all the great ideas in the
API. Looking forward to reviewing 0167 as well!

Cheers,
-C

On Thu, Apr 6, 2017 at 2:10 PM Douglas Gregor  wrote:

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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Colin Barrett via swift-evolution]

Ah that's right. Too bad! As I said I see the logic behind all the changes,
so I'm not opposed. Just wanted to bikeshed the operator a bit.

Thanks Doug,
-Colin

On Wed, Apr 5, 2017 at 8:00 PM Douglas Gregor  wrote:

> On Apr 5, 2017, at 4:55 PM, Colin Barrett 
> wrote:
>
> Is the choice of backslash up for review? I think another operator,
>
>
> We talked through basically everything on the keyboard, and there really
> aren’t other options that don’t stomp on existing behavior.
>
> perhaps backtick (`), would work better.
>
>
> Backtick (`) is already taken for escaping identifiers, e.g.,
>
> var `func` = { /* some code */ }
>
> - Doug
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Type-based ‘private’ access within a file

[Colin Barrett via swift-evolution]

I'm broadly in favor of this.

On Mon, Apr 3, 2017 at 2:35 PM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift Community,
>
> In rejecting SE-0159
> ,
> the core team described a potential direction we would like to investigate
> for “private” access control that admits a limited form of type-based
> access control within files. The core team is seeking some discussion here
> and a motivated volunteer to put together a proposal along these lines for
> review in the Swift 4 time-frame (i.e., very soon). To be clear, the core
> team it’s sure this is the right direction to go… but it appears promising
> and we would *love* to be able to settle the access-control issue.
>
> The design, specifically, is that a “private” member declared within a
> type “X” or an extension thereof would be accessible from:
>
> * An extension of “X” in the same file
> * The definition of “X”, if it occurs in the same file
> * A nested type (or extension thereof) of one of the above that occurs in
> the same file
>
> This design has a number of apparent benefits:
> + “private” becomes the right default for “less than whole module”
> visibility, and aligns well with Swift coding style that divides a type’s
> definition into a number of extensions.
> + “fileprivate” remains for existing use cases, but now it’s use it more
> rare, which has several advantages:
> + It fits well with the "progressive disclosure” philosophy behind Swift:
> you can use public/internal/private for a while before encountering and
> having to learn about “fileprivate”   (note: we thought this was going to
> be true of SE-0025
> ,
> but we were clearly wrong)
> + When “fileprivate” occurs, it means there’s some interesting coupling
> between different types in the same file. That makes fileprivate a useful
> alert to the reader rather than, potentially, something that we routinely
> use and overlook so that we can separate implementations into extensions.
> + “private” is more closely aligned with other programming languages that
> use type-based access control, which can help programmers just coming to
> Swift. When they reach for “private”, they’re likely to get something
> similar to what they expect—with a little Swift twist due to Swift’s heavy
> use of extensions.
> + Loosening the access restrictions on “private” is unlikely to break
> existing code.
>
> There are likely some drawbacks:
> - Developers using patterns that depend on the existing lexically-scoped
> access control of “private” may find this new interpretation of “private”
> to be insufficiently strict
> - Swift’s access control would go from “entirely lexical” to “partly
> lexical and partly type-based”, which can be viewed as being more
> complicated
>

I think it might not as complicated as it may first appear. I haven't fully
convinced myself of this, but I believe that it would be lexically
scoped *modulo
inlining extensions*.

To put it somewhat more formally (and awkwardly), if one imagines a textual
transformation which blindly inlines any extension in a single file into
their type definitions (should those definitions occur within that file)
then accessing a "private" member in the original file would compile if and
only if the access would be lexically scoped if the above postulated
transformation were to be applied to it.

This is a pleasing property (to me anyway) as it means that it is unlikely
(impossible?) for moving code from one extension (or definition) to another
to cause a compilation failure.

Take this with a grain of salt of course, as there's probably an edge case
I'm not thinking of :P (This is why we write proofs!)

Cheers,
-Colin


> Thoughts? Volunteer?
>
> - Doug
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Colin Barrett via swift-evolution]

Is the choice of backslash up for review? I think another operator, perhaps
backtick (`), would work better. My concern is with the \() escaping syntax
within strings, which has the opposite behavior wrt. execution time:

let untrue = "2 + 2 = \((5, print("inside")).0)"
print("outside")
print(untrue)
// output:
// "inside"
// "outside"
// "2 + 2 = 5"

If the purpose of the backslash syntax is to make the delayed execution
time clear, I don't believe it achieves that goal.

Love the proposal otherwise, and I for sure see the logic in making
Person.instanceMethod "look different" from Person.classOrStaticProperty.

-Colin

On Wed, Apr 5, 2017 at 7:01 PM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal Link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>
> Hello Swift community,
>
> The review of SE-0161 “Smart KeyPaths: Better Key-Value Coding for Swift”
> ran from March 30...April 5, 2017. The proposal was very well-received
> *except* that reviewers felt that the #keyPath syntax was far too heavy
> for this new language construct, and preferred the lighter-weight syntax of
> the pre-review drafts. This proposal is *returned for revision* to
> address the syntax.
>
> The heavyweight #keyPath syntax was requested by the core team after
> reviewing earlier drafts, which used a far lighter syntax:
>
> // (Rejected) syntax from pre-review drafts
> let firstFriendsNameKeyPath = Person.friends[0].name
> print(luke[keyPath: .friends[0].name])
>
> The core team’s specific concern was that these key path expressions
> (e.g., Person.friends[0].name) don’t make it sufficiently clear that the
> actual property accesses are being delayed, and that the contextual cues (“
> Person." vs. “luke.”) are insufficient to disambiguate for the human
> reader. Hence, the request for a different (more explicit) syntax.
>
> Reviewers rightly point out that it is natural for key-paths to use the
> same syntax as unapplied instance method references, e.g.,
> Person.someInstanceMethod produces a value of some function type with the
> “Self” type curried, e.g., (Person) -> (param-types) -> result-type. The
> core team agrees with this sentiment. The core team also felt that Swift’s
> existing unapplied method references suffer from the same clarity problems
> as the initial key-path syntax, i.e., that it isn’t sufficiently clear that
> the actual application of “self” is being delayed.
>
> The core team has a specific proposal: use the backslash (‘\’) to as a
> leading indicator for key paths. Specifically,
>
> // Proposed syntax for second revision
> let firstFriendsNameKeyPath = \Person.friends[0].name
> print(luke[keyPath: \.friends[0].name])
>
> The backslash is a visual cue that the actual application of this chain of
> property references is delayed, eliminating ambiguities, yet is still quite
> lightweight and feels “first-class” in the language.
>
> The core team felt that, in the future, the backslash should also be used
> for unapplied instance method references, to match the proposed syntax for
> key paths and improve clarity for this non obvious feature. This change
> could be staged in as a revision to the accepted-but-never-implemented 
> SE-0042:
> Flattening the function type of unapplied method references
> ,
> e.g.,
>
> // Proposed future syntax for unapplied instance method references
> class Person {
>   func instanceMethod(_: String) -> Int { … }
> }
>
> let f1 = Person.instanceMethod   // to-be-deprecated; produces a value of
> type (Person) -> (String) -> Int
> let f2 = \Person.instanceMethod  // to-be-introduced via a revised
> SE-0042: produces a value of type (Person, String) -> Int
>
> Such an approach gives us a way to stage in SE-0042 and get to eventual
> consistency between key paths and unapplied instance method references.
>
> - Doug
> Review Manager
>
>
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Colin Barrett via swift-evolution]

Hi Itai,

On Tue, Mar 21, 2017 at 1:03 PM Itai Ferber  wrote:

Hi Colin,

Thanks for your comments! Are you talking about Codable synthesis, or
encoding in general?

Yeah, I meant specifically in the case where things are synthesized
automatically. As you point out below, if someone implements a custom
Codeable instance, all bets are off.

On 21 Mar 2017, at 8:44, Colin Barrett wrote:

Hi Itai,

Glad to see these proposal! I'm curious, have you or the other Swift folks
thought about how *users* of these new Codable protocols will interact with
resilience domains?

What I mean is that what appear to be private or internal identifiers, and
thus changeable at will, may actually be fragile in that changing them will
break the ability to decode archives encoded by previous versions.

Making this safer could mean:
- Encoding only public properties

Unfortunately, property accessibility in code does not always map 1-to-1
with accessibility for archival (nor do I think they should be tied to one
another).
There are certainly cases where you’d want to include private information
in an archive, but that is not useful to expose to external clients, e.g.,
a struct/class version:

public struct MyFoo {
// Should be encoded.
public var title: String
public var identifier: Int

// This should be encoded too — in case the struct changes in the
// future, want to be able to refer to the payload version.
private let version = 1.0
}

Of course, there can also be public properties that you don’t find useful
to encode. At the moment, I’m not sure there’s a much better answer than
"the author of the code will have to think about the representation of
their data"; even if there were an easier way to annotate "I definitely
want this to be archived"/"I definitely don’t want this to be archived",
the annotation would still need to be manual.

(The above applies primarily in the case of Codable synthesis; when
implementing Codable manually I don’t think the compiler should ever
prevent you from doing what you need.)

- Adding some form of indirection (a la ObjC non-fragile ivars?)

What do you mean by this?

I'm not sure exactly how or if it would work in-detail, unfortunately, but
I know that the ObjC runtime emits symbols which are used to lookup the
offset in the object struct for non-fragile ivars. Maybe some similar form
of indirection would be useful for encoding non-public ivars. Like I said,
don't know exactly how/if that would work, just sharing :)


- Compiler warning (or disallowing) changes to properties in certain
situations.

We’ve thought about this with regards to identifying classes uniquely
across renaming, moving modules, etc.; this is a resilience problem in
general.
In order for the compiler to know about changes to your code it’d need to
keep state across compilations. While possible, this feels pretty fragile
(and potentially not very portable).

   - Compiler warns about changing a property? Blow away the cache
   directory!
   - Cloning the code to a new machine for the first time? Hmm, all the
   warnings went away…

This would be nice to have, but yes:

I imagine the specifics would need to follow the rest of the plans for
resilience.

specifics on this would likely be in line with the rest of resilience plans
for Swift in general.


Right. Thus my concern about allowing non-public fields to be automatically
serialized. The most conservative option would be to only automatically
synthesize a Codeable instance for the public members of public types.
Seems overly restrictive, so maybe anything goes for internal types, or
there's some sort of warning (overridable via an attribute?)

I want to emphasize btw that I'm enthusiastic about this proposal in
general. The support for integer keys is welcome and, as it's one of my pet
projects, eases support for a Cap'n Proto-style serialization format.[1]

-Colin

[1]: https://capnproto.org

It's likely that this could be addressed by a future proposal, as for the
time being developers can simply "not hold it wrong" ;)

Thanks,
-Colin

On Wed, Mar 15, 2017 at 6:52 PM Itai Ferber via swift-evolution <
swift-evolution@swift.org> wrote:

Hi everyone,

The following introduces a new Swift-focused archival and serialization
API as part of the Foundation framework. We’re interested in improving the
experience and safety of performing archival and serialization, and are
happy to receive community feedback on this work.

Because of the length of this proposal, the *Appendix* and *Alternatives
Considered* sections have been omitted here, but are available in the full
proposal  on the
swift-evolution repo. The full proposal also includes an *Unabridged API*
for


further consideration.

Without further ado, inlined below.

— Itai

Swift Archival & Serialization

- Proposal: SE- 
- Author(s): Itai Ferber 

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

[Colin Barrett via swift-evolution]

I'm not sure I follow. What do you mean "which strategy to use for a given
encoding"? IMO there should be at most one implementation of Coding /
Decoding for a particular type. So the way you'd say "I want to decode a
JSON response that implements my blog model" would be, reusing the
definition from above

let wblog = try JSONDecoder().decode(WebBlogModel.self, from: payload)
let blog = wblog.wrapped

What am I missing?

-Colin


On Tue, Mar 21, 2017 at 12:16 PM Matthew Johnson <matt...@anandabits.com>
wrote:

> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Here's what I mean: Suppose I have a BlogPost model, and I can both fetch
> and post BlogPosts to a cross-platform web service, and store them locally.
> But when I fetch and post remotely, I ned to conform to the web service's
> formats; when I store an instance locally, I have a freer hand in designing
> my storage, and perhaps need to store some extra metadata. How do you
> imagine handling that sort of situation? Is the answer simply that I should
> use two different types?
>
> This is a valid concern, and one that should likely be addressed.
>
> Perhaps the solution is to offer a userInfo : [UserInfoKey : Any] (
> UserInfoKey being a String-RawRepresentable struct or similar) on Encoder
> and Decoder set at the top-level to allow passing this type of contextual
> information from the top level down.
>
>
> I assumed that in those situations, one would create a wrapper struct,
>
> struct WebBlogModel {
> let wrapped: BlogModel
> }
>
> probably for the encoding impl that requires more custom work. The
> implementation of Codable for this struct would then serialize
> (deserialize) from (to) its wrapped value's properties directly.
>
> Types already provide a means for performing context sensitive
> implementation selection, I don't think it's necessary to provide another
> way to do that in Swift. Of course I could very well be wrong :)
>
>
> Wrappers like this give you a way to *implement* different encoding
> strategies but they don’t help you identify which strategy to use for a
> given encoding.  You need a user-defined context to do that.  Brent has
> proposed a couple of different designs to facilitate this which are nicer
> than a user info dictionary.
>
>
> -Colin
>
> ___
> 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

[Colin Barrett via swift-evolution]

On Mon, Mar 20, 2017 at 7:54 PM Douglas Gregor  wrote:

> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs
> through March 27, 2017. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>
> Reply text
>
> Other replies
>
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>
> -1. The proposal does not make a convincing case for why this is a
problem.


>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Having to write "fileprivate" seems like a pretty minor annoyance.
Especially when compared to having to move any desired private data to a
new file. In my view, the primary purpose of access modifiers below
internal is to keep autocomplete from suggesting implementation details to
clients.
,

>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Given that in other places in Swift, scoping often corresponds with
lexical structure, making "private" an exception seems surprising.
"fileprivate" succinctly communicates this oddity.


>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> I've got a decent amount of experience with access control in Java,
Python, Haskell, and Standard ML.


>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
>  I read the proposal once. (I didn't have time to read the follow-ups
on-list, apologies for any noise.)


> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Colin Barrett via swift-evolution]

On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Here's what I mean: Suppose I have a BlogPost model, and I can both fetch
> and post BlogPosts to a cross-platform web service, and store them locally.
> But when I fetch and post remotely, I ned to conform to the web service's
> formats; when I store an instance locally, I have a freer hand in designing
> my storage, and perhaps need to store some extra metadata. How do you
> imagine handling that sort of situation? Is the answer simply that I should
> use two different types?
>
> This is a valid concern, and one that should likely be addressed.
>
> Perhaps the solution is to offer a userInfo : [UserInfoKey : Any] (
> UserInfoKey being a String-RawRepresentable struct or similar) on Encoder
> and Decoder set at the top-level to allow passing this type of contextual
> information from the top level down.
>

I assumed that in those situations, one would create a wrapper struct,

struct WebBlogModel {
let wrapped: BlogModel
}

probably for the encoding impl that requires more custom work. The
implementation of Codable for this struct would then serialize
(deserialize) from (to) its wrapped value's properties directly.

Types already provide a means for performing context sensitive
implementation selection, I don't think it's necessary to provide another
way to do that in Swift. Of course I could very well be wrong :)

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

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

[Colin Barrett via swift-evolution]

Hi Itai,

Glad to see these proposal! I'm curious, have you or the other Swift folks
thought about how *users* of these new Codable protocols will interact with
resilience domains?

What I mean is that what appear to be private or internal identifiers, and
thus changeable at will, may actually be fragile in that changing them will
break the ability to decode archives encoded by previous versions.

Making this safer could mean:
- Encoding only public properties
- Adding some form of indirection (a la ObjC non-fragile ivars?)
- Compiler warning (or disallowing) changes to properties in certain
situations.

I imagine the specifics would need to follow the rest of the plans for
resilience.

It's likely that this could be addressed by a future proposal, as for the
time being developers can simply "not hold it wrong" ;)

Thanks,
-Colin

On Wed, Mar 15, 2017 at 6:52 PM Itai Ferber via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi everyone,
>
> The following introduces a new Swift-focused archival and serialization
> API as part of the Foundation framework. We’re interested in improving the
> experience and safety of performing archival and serialization, and are
> happy to receive community feedback on this work.
> Because of the length of this proposal, the *Appendix* and *Alternatives
> Considered* sections have been omitted here, but are available in the full
> proposal  on the
> swift-evolution repo. The full proposal also includes an *Unabridged API* for
> further consideration.
>
> Without further ado, inlined below.
>
> — Itai
>
> Swift Archival & Serialization
>
>- Proposal: SE- 
>- Author(s): Itai Ferber , Michael LeHew
>, Tony Parker 
>- Review Manager: TBD
>- Status: *Awaiting review*
>- Associated PRs:
>   - #8124 
>   - #8125 
>
> Introduction
>
> Foundation's current archival and serialization APIs (NSCoding,
> NSJSONSerialization, NSPropertyListSerialization, etc.), while fitting
> for the dynamism of Objective-C, do not always map optimally into Swift.
> This document lays out the design of an updated API that improves the
> developer experience of performing archival and serialization in Swift.
>
> Specifically:
>
>- It aims to provide a solution for the archival of Swift struct and
>enum types
>- It aims to provide a more type-safe solution for serializing to
>external formats, such as JSON and plist
>
> Motivation
>
> The primary motivation for this proposal is the inclusion of native Swift
> enum and struct types in archival and serialization. Currently,
> developers targeting Swift cannot participate in NSCoding without being
> willing to abandon enum and structtypes — NSCoding is an @objc protocol,
> conformance to which excludes non-class types. This is can be limiting in
> Swift because small enums and structs can be an idiomatic approach to
> model representation; developers who wish to perform archival have to
> either forgo the Swift niceties that constructs like enumsprovide, or
> provide an additional compatibility layer between their "real" types and
> their archivable types.
>
> Secondarily, we would like to refine Foundation's existing serialization
> APIs (NSJSONSerialization and NSPropertyListSerialization) to better
> match Swift's strong type safety. From experience, we find that the
> conversion from the unstructured, untyped data of these formats into
> strongly-typed data structures is a good fit for archival mechanisms,
> rather than taking the less safe approach that 3rd-party JSON conversion
> approaches have taken (described further in an appendix below).
>
> We would like to offer a solution to these problems without sacrificing
> ease of use or type safety.
> Agenda
>
> This proposal is the first stage of three that introduce different facets
> of a whole Swift archival and serialization API:
>
>1. This proposal describes the basis for this API, focusing on the
>protocols that users adopt and interface with
>2. The next stage will propose specific API for new encoders
>3. The final stage will discuss how this new API will interop with
>NSCoding as it is today
>
> SE- provides stages 2 and 3.
> Proposed solution
>
> We will be introducing the following new types:
>
>- protocol Codable: Adopted by types to opt into archival. Conformance
>may be automatically derived in cases where all properties are also
>Codable.
>- protocol CodingKey: Adopted by types used as keys for keyed
>containers, replacing String keys with semantic types. Conformance may
>be automatically derived in most cases.
>- protocol Encoder: Adopted by types which can take Codable values and
>encode them into a native 

Re: [swift-evolution] Smart KeyPaths

[Colin Barrett via swift-evolution]

It's so nice that this is finally seeing the light of day :) Great work
everyone!

Re: subscripts, it's definitely a great solution for "the Swift we have
now", but I'm not sure in "the Swift we'll have in a few years." If, for
instance, someday we're able to return inouts (or really just lvalues in
general), we'd be able to do a lot of this with regular functions and some
combinators.

Count me as a +1 for the Lisp-style syntax. If ` isn't to people's liking,
I wonder about @. I think both "luke @  .friends[0].name" and "
.friends[0].name @ luke" read quiet nicely, and gives the idea of a key
path as a kind of addressing scheme.

-Colin

P.S. Has anyone thought about writing an HTTP + JSON DSL with these?

On Fri, Mar 17, 2017 at 1:04 PM Michael LeHew via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi friendly swift-evolution folks,
>
> The Foundation and Swift team  would like for you to consider the
> following proposal:
>
> Many thanks,
> -Michael
>
> Smart KeyPaths: Better Key-Value Coding for Swift
>
>- Proposal: SE-
>- Authors: David Smith , Michael LeHew
>, Joe Groff 
>- Review Manager: TBD
>- Status: *Awaiting Review*
>- Associated PRs:
>   - #644 
>
> Introduction
>
> We propose a family of concrete *Key Path* types that represent uninvoked
> references to properties that can be composed to form paths through many
> values and directly get/set their underlying values.
> MotivationWe Can Do Better than String
>
> On Darwin platforms Swift's existing #keyPath() syntax provides a
> convenient way to safely *refer* to properties. Unfortunately, once
> validated, the expression becomes a String which has a number of
> important limitations:
>
>- Loss of type information (requiring awkward Any APIs)
>- Unnecessarily slow to parse
>- Only applicable to NSObjects
>- Limited to Darwin platforms
>
> Use/Mention Distinctions
>
> While methods can be referred to without invoking them (let x = foo.bar 
> instead
> of  let x = foo.bar()), this is not currently possible for properties and
> subscripts.
>
> Making indirect references to a properties' concrete types also lets us
> expose metadata about the property, and in the future additional behaviors.
> More Expressive KeyPaths
>
> We would also like to support being able to use *Key Paths* to access
> into collections, which is not currently possible.
> Proposed solution
>
> We propose introducing a new expression akin to Type.method, but for
> properties and subscripts. These property reference expressions produce
> KeyPath objects, rather than Strings. KeyPaths are a family of generic
> classes *(structs and protocols here would be ideal, but requires
> generalized existentials)* which encapsulate a property reference or
> chain of property references, including the type, mutability, property
> name(s), and ability to set/get values.
>
> Here's a sample of it in use:
> Swift
>
> struct Person {
> var name: String
> var friends: [Person]
> var bestFriend: Person?}
> var han = Person(name: "Han Solo", friends: [])var luke = Person(name: "Luke 
> Skywalker", friends: [han])
> let firstFriendsNameKeyPath = Person.friends[0].name
> let firstFriend = luke[path] // han
> // or equivalently, with type inferred from contextlet firstFriendName = 
> luke[.friends[0].name]
> // rename Luke's first friend
> luke[firstFriendsNameKeyPath] = "A Disreputable Smuggler"
> let bestFriendsName = luke[.bestFriend]?.name  // nil, if he is the last jedi
>
> Detailed designCore KeyPath Types
>
> KeyPaths are a hierarchy of progressively more specific classes, based on
> whether we have prior knowledge of the path through the object graph we
> wish to traverse.
> Unknown Path / Unknown Root Type
>
> AnyKeyPath is fully type-erased, referring to 'any route' through an
> object/value graph for 'any root'. Because of type-erasure many operations
> can fail at runtime and are thus nillable.
> Swift
>
> class AnyKeyPath: CustomDebugStringConvertible, Hashable {
> // MARK - Composition
> // Returns nil if path.rootType != self.valueType
> func appending(path: AnyKeyPath) -> AnyKeyPath?
>
> // MARK - Runtime Information
> class var rootType: Any.Type
> class var valueType: Any.Type
>
> static func == (lhs: AnyKeyPath, rhs: AnyKeyPath) -> Bool
> var hashValue: Int}
>
> Unknown Path / Known Root Type
>
> If we know a little more type information (what kind of thing the key path
> is relative to), then we can use PartialKeyPath , which refers to
> an 'any route' from a known root:
> Swift
>
> class PartialKeyPath: AnyKeyPath {
> // MARK - Composition
> // Returns nil if Value != self.valueType
> func appending(path: AnyKeyPath) -> PartialKeyPath?
> func appending(path: KeyPath) 
> -> 

Re: [swift-evolution] [Proposal] Typed throws

[Colin Barrett via swift-evolution]

On Sun, Feb 19, 2017 at 2:34 PM Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> Now that I think about it, generic throws does not exactly cover rethrows.
> Firstly, rethrows has semantic information that function itself does not
> throw—it would be lost.
>

That's not true. Parametric polymorphism guarantees that rethrows and
polymorphic throw are the same.

For example, you can prove that as a consequence of parametricity that
there is only one (pure) function in the of the set of all functions with
the type ``forall A. A -> A'' and furthermore that it is the identity
function.

The intuition behind this is that you (meaning the fiction; imagine being a
function!) cannot construct your own value of "A" since you don't have any
information about what "A" is. The only place to get an "A" is from your
argument.

Secondly, rethrows allows a function with multiple throwing function
> parameters to become non-throwing iff all the arguments are non-throwing.
> How would you express it with generics?
> In the proposal, in this case you are required to provide a non-generic
> supertype of all used error types. This type can’t just turn into Never
> automatically.
>
> One solution would be to retain rethrows as an additional attribute.
> It would help with semantic information, and resulting error will be able
> to turn into Never as a special case—now that we know, that this function
> doesn’t throw that error itself.
>
> 2017-02-19 0:16 GMT+03:00 Martin Waitz :
>
>
> Am 18.02.2017 um 17:37 schrieb Matthew Johnson via swift-evolution <
> swift-evolution@swift.org>:
>
> Thank you for taking the time to put this proposal together Anton!  I
> really want to see typed throws make it into Swift 4.  This will be a very
> nice feature to have.
>
> I noticed that you included Joe Groff’s idea of replacing `rethrows` by
> making every function have an error type which is by default `Never` for
> non-throwing functions and `Error` for throwing functions that do not
> specify an error type.
>
> I want to urge you to consider updating the proposal to take this
> direction now rather than later.  This is a breaking change which means the
> longer we wait the harder it is to justify.  In fact, I think incorporating
> the breaking change could increase the chances of it being accepted for
> Swift 4.  Without that it is a purely additive change and those are not
> being given priority in the Swift 4 release.
>
>
> Seconded.
> With typed throwing function parameters, it makes a lot of sense to be
> able to specify the rethrown type, based on the function given as parameter.
>
> ​
> ___
> 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] [Re-Review] SE-0104: Protocol-oriented integers

[Colin Barrett via swift-evolution]

Pardon for the misfire; I switched to a new mail client recently and it
didn't behave as I was expecting.

I was intending to reply to Jordan's comments upthread about popCount.

On Tue, Feb 21, 2017 at 7:28 PM Colin Barrett 
wrote:

> I'm not sure exactly where the bar is, but chiming in that recently, in
> implementing generic succinct data structures as an exercise, I needed to
> define exactly this operation generically.
>
> -Colin
> On Tue, Feb 21, 2017 at 6:29 PM Max Moiseev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Feb 21, 2017, at 3:05 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs
> through February 25, 2017. This proposal was accepted for Swift 3, but was
> not implemented in time for the release. The revised proposal is available
> here:
>
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>
>
> • What is your evaluation of the proposal?
>
>
> Well worth while. Few nit picks:
>
>   1. Number.init? Description should say BinaryInteger not floating-point.
>
> I’ll update the proposal.
>
>   2. Number should document that mutating versions of operators can
> overflow.
>   3. SignedNumber should document that negate and unary `-` can overflow.
>
> Documentation changes noted. Thanks!
>
>   4. SignedNumber, it is weird that `signum` is a function when other
> similar things, e.g. `magnitude`, are properties.
>
> I think of it as: magnitude is something the number ‘has’ whereas signum
> is a completely new thing of the same type.
>
>   5. Not worth representing `DoubleWidth` as an enumeration, it is obscure
> and therefore will only confuse people.
>   6. It would be better to put the 'extra' operations into the protocols
> and provide default implementations, otherwise they are difficult to find.
>
> They are defined as protocol extensions, therefore they should be
> discoverable through completion and in the generated source code. Or what
> do you mean by ‘difficult to find’?
>
> Thanks for the feedback!
>
>
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
>
>
> Yes, the current design has not served my purpose on more than one
> occasion
>
>
> • Does this proposal fit well with the feel and direction of Swift?
>
>
> Yes
>
>
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
>
> Yes, this proposal is similar to what other languages provide, e.g. Scala.
> In Scala however they tackle the `conversion problem as well in their
> `traits heirarchy. I guess this could be added at a later date.
>
>
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> Read the proposal, have used similar features in other languages, and have
> had trouble with Swift's current heirarchy.
> --
> -- Howard.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Re-Review] SE-0104: Protocol-oriented integers

[Colin Barrett via swift-evolution]

I'm not sure exactly where the bar is, but chiming in that recently, in
implementing generic succinct data structures as an exercise, I needed to
define exactly this operation generically.

-Colin
On Tue, Feb 21, 2017 at 6:29 PM Max Moiseev via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 21, 2017, at 3:05 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs
> through February 25, 2017. This proposal was accepted for Swift 3, but was
> not implemented in time for the release. The revised proposal is available
> here:
>
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>
>
> • What is your evaluation of the proposal?
>
>
> Well worth while. Few nit picks:
>
>   1. Number.init? Description should say BinaryInteger not floating-point.
>
> I’ll update the proposal.
>
>   2. Number should document that mutating versions of operators can
> overflow.
>   3. SignedNumber should document that negate and unary `-` can overflow.
>
> Documentation changes noted. Thanks!
>
>   4. SignedNumber, it is weird that `signum` is a function when other
> similar things, e.g. `magnitude`, are properties.
>
> I think of it as: magnitude is something the number ‘has’ whereas signum
> is a completely new thing of the same type.
>
>   5. Not worth representing `DoubleWidth` as an enumeration, it is obscure
> and therefore will only confuse people.
>   6. It would be better to put the 'extra' operations into the protocols
> and provide default implementations, otherwise they are difficult to find.
>
> They are defined as protocol extensions, therefore they should be
> discoverable through completion and in the generated source code. Or what
> do you mean by ‘difficult to find’?
>
> Thanks for the feedback!
>
>
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
>
>
> Yes, the current design has not served my purpose on more than one
> occasion
>
>
> • Does this proposal fit well with the feel and direction of Swift?
>
>
> Yes
>
>
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
>
> Yes, this proposal is similar to what other languages provide, e.g. Scala.
> In Scala however they tackle the `conversion problem as well in their
> `traits heirarchy. I guess this could be added at a later date.
>
>
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> Read the proposal, have used similar features in other languages, and have
> had trouble with Swift's current heirarchy.
> --
> -- Howard.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Colin Barrett via swift-evolution]

On Fri, Feb 17, 2017 at 4:46 PM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I suggest we need to find a way to shorten the list of the possible error
> types with a the help of typeallias
>
> extension MyError1: Error { ... }
> extension MyError2: Error { ... }
> extension MyError3: Error { ... }
>
> typealias MyErrors = MyError1 | MyError2 | MyError3
>
> func foo() throws(MyErrors) -> MyResult
> func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult
>
> Do you actually need that? Experience in other languages like Rust and
> Haskell that use Result-based error propagation suggests that a single
> error type is adequate, and beneficial in many ways. If nothing else, you
> could `Either` your way to multiple errors if you really needed to.
>
> IMO, if we accept a single error type per function, there could be a
> simpler model for this. We could say that the `throws` type is a generic
> parameter of all function types, and it defaults to the uninhabited `Never`
> type for functions that don't throw.
>
> () -> () == () throws Never -> ()
> () throws -> () == () throws Error -> ()
>
> In this model, you'd get many benefits:
>
> - `rethrows` could become first-class, reducing down to just polymorphic
> `throws`:
>
> func foo(_: () throws -> ()) rethrows // Swift 3
> func foo(_: () throws T -> ()) throws T // Swift X
> func foo(_: () throws T -> ()) throws Either
>
> - Protocols could abstract over error handling; for instance, we could
> support throwing sequences:
>
> protocol IteratorProtocol {
>   associatedtype Element
>   associatedtype Error: Swift.Error = Never
>
>   mutating func next() throws Error -> Element?
> }
>
>
I really dig this proposal, Joe. Matches my experience from other languages
as well.

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Colin Barrett via swift-evolution]

> On Oct 22, 2016, at 8:53 PM, Jonathan S. Shapiro 
>  wrote:
> 
> I missed this earlier posting from Joe Groff, who wrote:
> 
> In the discussion about operators, I wonder whether it makes sense to 
> formally separate "identifier" and "operator" characters at all. ...
> 
> The consequence if we do not formally separate the operators (verbs) from the 
> identifiers (nouns) is that white space will be needed around all operators. 
> That's not necessarily a bad thing, but it would be a significant and 
> incompatible departure from today's Swift, both in terms of actual source 
> code breakage and in terms of the "look and feel" that many people feel 
> passionate about.

That’s one way yeah. Or you’d could to make the grammar context sensitive / 
apply a "lexer hack”. Probably other ways to deal w/ context sensitivity as 
well. Joe’s proposed syntax seems pretty explicit, and hopefully it’sdsimple to 
plumb / capture that info in the lexer. (I’m ignorant of the implementation of 
Swift’s front-end unfortunately!)

-Colin

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Colin Barrett via swift-evolution]

I’m a -1 on the original proposal. I can see the logic in doing things that 
way, but it’s really unclear to me why we need to act *now*. In fact it seems 
like waiting might be a better option, given the things mentioned upthread 
about revisions to the Unicode standard.

Also, I think the message quoted below is a promising direction worth 
exploring. How would something like this work in the front-end? Swift’s grammar 
currently distinguishes between operators and identifiers right?

-Colin

> On Oct 19, 2016, at 12:17 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> I think this is a promising direction. Getting us in line with Unicode 
> recommendations is an important first step, and being conservative about the 
> treatment of operator characters and emoji is a good engineering approach, 
> though certainly unfortunate in the short term for users who've adopted 
> custom operators or found interesting uses for emoji identifiers in Swift 3 
> and earlier.
> 
> In the discussion about operators, I wonder whether it makes sense to 
> formally separate "identifier" and "operator" characters at all. My hunch is 
> that there isn't going to be any perfect categorization; there are so many 
> symbols and scripts out there that it's going to be difficult to definitively 
> characterize many symbols as "obviously" an operator or identifier. Not every 
> developer has the mathematical background to even recognize common math 
> operators beyond the elementary arithmetic ones. Something to consider would 
> be to change the way operators work in the language so that they can use 
> *any* symbols (subject to canonicalization, visibility, and confusability 
> constraints), but require their use to always be explicitly declared in a 
> source file that uses an operator outside of the standard library. For 
> example, you would have to say something like:
> 
> import Sets
> import operator Sets.∪
> 
> to make the '∪' symbol available as an operator in the import declaration's 
> scope. This would provide more obvious evidence in the source code of what 
> tokens are being employed as operators, and lessen the need to have formally 
> distinct identifier and operator character sets.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] deprecating ManagedBufferPointer

[Colin Barrett via swift-evolution]

May be totally wrong about this but I always thought that 
ManagedBuffer(Pointer) would be really useful in conjunction w/ Metal. In 
particular, MTLBuffer gives you a region of memory that is in common 
configurations shared btwn the CPU and GPU. I believe the idea is you write 
your vertex data or textures or whatever into that region, which you then 
associate with a particular command you issue to the GPU.

-Colin

> On Oct 19, 2016, at 6:28 PM, Alexis via swift-evolution 
>  wrote:
> 
> A bit late to this game, because I didn’t fully understand the “point” of 
> ManagedBuffer(Pointer). After a good week of messing around with these in 
> Dictionary/Array/String, I now have Opinions.
> 
> I agree ManagedBufferPointer is largely unnecessary. However it’s seeming a 
> lot like ManagedBuffer (and its equivalents) are suboptimal for the standard 
> library’s purposes too!
> 
> In particular, pretty much every one of these buffers that I see wants to be 
> a subclass of some NS* collection so that it can be toll-free bridged into 
> objective C. This means that all those types are forced to directly drop down 
> to allocWithTailElems, rather than using a nice abstraction that does it for 
> them. Array does this right now, and I’ve got a PR up for review that’s doing 
> the same thing to the HashedCollections. It’s an outstanding bug that String 
> isn’t doing this (forcing its buffer to be wrapped in another class to be 
> bridged).
> 
> I don’t really feel any pain from directly using allocWithTailElems, it’s a 
> great API. It just leaves me at a loss for when I’d reach for ManagedBuffer 
> at all, as it’s very limited.
> 
> 
>> On Oct 13, 2016, at 3:11 PM, Erik Eckstein via swift-evolution 
>> > wrote:
>> 
>> I created a proposal: https://github.com/apple/swift-evolution/pull/545 
>> 
>> 
>>> On Oct 11, 2016, at 11:32 PM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> on Tue Oct 11 2016, Károly Lőrentey >> > wrote:
>>> 
 +1
 
 ManagedBuffer has been really useful a couple of times, but I never
 found a use for ManagedBufferPointer. I can’t even say I’m entirely
 sure what need it was originally designed to fulfill.
>>> 
>>> The real need is/was to be able to do the same kind of storage
>>> management in classes not derived from ManagedBuffer.  This can be
>>> important for bridging, where the buffers of various native swift
>>> containers need to be derived from, e.g., NSString or NSArray.  That is,
>>> however, an extremely stdlib-specifc need.
>>> 
>>> 
> On 2016-10-11, at 00:12, Erik Eckstein via swift-evolution
 > wrote:
> 
> The purpose of ManagedBufferPointer is to create a buffer with a custom 
> class-metadata to be able
 to implement a custom deinit (e.g. to destroy the tail allocated elements).
> It was used in Array (before I replaced it with the new 
> tail-allocated-array-built-ins). But now
 it’s not used anymore in the standard library.
> 
> As a replacement for ManagedBufferPointer one can just derive a class 
> from ManagedBuffer and implement the deinit in the derived class.
> 
> final class MyBuffer : ManagedBuffer {
>  deinit {
>// do whatever needs to be done
>  }
> }
> 
> // creating MyBuffer:
> let b = MyBuffer.create(minimumCapacity: 27, makingHeaderWith: { myb in 
> return MyHeader(...) })
> 
> IMO ManagedBuffer is much cleaner than ManagedBufferPointer (it doesn’t 
> need this custom
 bufferClass to be passed to the constructor). Also ManagedBufferPointer 
 doesn’t use SIL
 tail-allocated arrays internally. Although this is not something visible 
 to the programmer, it makes
 life easier for the compiler.
> 
> So I suggest that we deprecate ManagedBufferPointer.
> 
> Erik
> ___
> 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 
 
 
>>> 
>>> -- 
>>> -Dave
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> 

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Colin Barrett via swift-evolution]

Definitely well motivated. It seems like having both .enumerated() and 
.indexed() methods would still leave open the possibility of novices using 
.enumerated and making the same mistake as before. I realize that because of 
where .enumerated() sits it has to work the way it does, but is there perhaps a 
better design (with constrained extensions?) for a single method that can give 
an Int for a Sequence and an appropriate Index for a Collection?

-Colin

> On Sep 28, 2016, at 1:55 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2 
> 
> 
> Introducing indexed() collections
> 
> Proposal: TBD
> Author: Erica Sadun , Nate Cook 
> , Jacob Bandes-Storch 
> , Kevin Ballard 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> This proposal introduces indexed() to the standard library, a method on 
> collections that returns an (index, element) tuple sequence.
> 
> Swift-evolution thread: TBD 
>  
> Motivation
> 
> The standard library's enumerated() method returns a sequence of pairs 
> enumerating a sequence. The pair's first member is a monotonically 
> incrementing integer starting at zero, and the second member is the 
> corresponding element of the sequence. When working with arrays, the integer 
> is coincidentally the same type and value as an Array index but the 
> enumerated value is not generated with index-specific semantics. This may 
> lead to confusion when developers attempt to subscript a non-array collection 
> with enumerated integers. It can introduce serious bugs when developers use 
> enumerated()-based integer subscripting with non-zero-based array slices.
> 
> Indices have a specific, fixed meaning in Swift, which are used to create 
> valid collection subscripts. This proposal introduces indexed() to produce a 
> more semantically relevant sequence by pairing a collection's indices with 
> its members. While it is trivial to create a solution in Swift, the most 
> common developer approach shown here calculates indexes twice: 
> 
> extension Collection {
> /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents a
> /// consecutive collection index, and *x* represents an element of
> /// the sequence.
> func indexed() -> Zip2Sequence {
> return zip(indices, self)
> }
> }
> Incrementing an index in some collections can be unnecessarily costly. In a 
> lazy filtered collection, an index increment is potentially O(N). We feel 
> this is better addressed introducing a new function into the Standard Library 
> to provide a more efficient design that avoids the attractive nuisance of the 
> "obvious" solution.
> 
>  
> Detailed
>  Design
> 
> Our vision of indexed() bypasses duplicated index generation with their 
> potentially high computation costs. We'd create an iterator that calculates 
> each index once and then applies that index to subscript the collection. 
> Implementation would take place through IndexedSequence, similar to 
> EnumeratedSequence.
> 
>  
> Impact
>  on Existing Code
> 
> This proposal is purely additive and has no impact on existing code.
> 
>  
> Alternatives
>  Considered
> 
> Not yet
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Refactor Metatypes

[Colin Barrett via swift-evolution]

First off, I agree with Nevin (up-thread) that this is a much clearer version 
of the previous proposal, well done.

> On Sep 28, 2016, at 6:18 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Formatted version: 
> https://github.com/DevAndArtist/swift-evolution/blob/refactor_metatypes/proposals/0126-refactor-metatypes.md
>  
> 
> Refactor Metatypes
> 
> Proposal: SE–0126 
> 
> Authors: Adrian Zubarev , Anton Zhilin 
> , Brent Royal-Gordon 
> Status: Revision
> Review manager: Chris Lattner 
> Revision: 2
> Previous Revisions: 1 
> 
> Introduction
> 
> This proposal removes .Type and .Protocol in favor of two generic-style 
> syntaxes and aligns global type(of:) function (SE–0096) to match the changes.
> 
> Swift-evolution thread (post Swift 3): 
> 
> [Pitch] Refactor Metatypes 
> 
> Older swift-evolution threads: [1] 
> ,
>  [2] 
> ,
>  [3] 
> 
> Motivation
> 
> Every type T has an instance, accessible through T.self, which represents the 
> type itself. Like all instances in Swift, this “type instance” itself has a 
> type, which is referred to as its “metatype”. The metatype of T is written 
> T.Type. The instance members of the metatype are the same as the static or 
> class members of the type.
> 
> Metatypes have subtype relationships which reflect the types they represent. 
> For instance, given these types:
> 
> protocol Proto {}
> class Base {}
> class Derived: Base, Proto {}
> Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type). 
> That means that Derived.self can be used anywhere a Derived.Type, Base.Type, 
> Proto.Type, or Any.Type is called for.
> 
> Unfortunately, this simple picture is complicated by protocols. Proto.self is 
> actually of type Proto.Protocol, not type Proto.Type. This is necessary 
> because the protocol does not, and cannot, conform to itself; it requires 
> conforming types to provide static members, but it doesn’t actually provide 
> those members itself. Proto.Type still exists, but it is the supertype of all 
> types conforming to the protocol.
> 
> Making this worse, a generic type always uses T.Type to refer to the type of 
> T.self. So when Proto is bound to a generic parameter P, P.Type is the same 
> as Proto.Protocol.
> 
> This shifting of types is complicated and confusing; we seek to clean up this 
> area.
> 
> We also believe that, in the long term, the dot syntax will prevent us from 
> implementing certain future enhancements that might be valuable:
> 
> Moving the implementation of metatypes at least partly into the standard 
> library.
> Adding members available on all type instances for features like read-write 
> reflection or memory layout information.
> Conforming metatypes to protocols like Hashable or CustomStringConvertible.
> Offering straightforward syntaxes for dynamic features like looking up types 
> by name.
> Proposed solution
> 
> We abolish .Type and .Protocol in favor of two generic-style syntaxes:
> 
> Type is the concrete type of T.self. A Type only ever has one instance, 
> T.self; even if T has a subtype U, Type is not a subtype of Type.
> 
> Subtype is the supertype of all Types whose instances are subtypes of T, 
> including T itself:
> 
> If T is a struct or enum, then Type is the only subtype of Subtype.
> 
> If T is a class, then Type and the Types of all subclasses of T are 
> subtypes of Subtype.
> 
> If T is a protocol, then the Types of all concrete types conforming to T are 
> subtypes of Subtype. Type is not itself a subtype of Subtype, or of 
> any Subtype other than Subtype.
> 
I’m having trouble reconciling this with rule #2 above, which states that 
“Subtype is the supertype of all Types whose instances are subtypes of T, 
including T itself.” Which one is wrong, or am I confused?

One thing I haven’t understood the motivation for exactly is what someone would 
be able to do with a Proto.self. Dynamic conformance checking? For a concrete 
T, having its .self seems useful for doing dynamic casts and such, but I don’t 
understand why for a Proto you need to have both. You did a good job of 
explaining why T.Protocol and T.Type are different, but not why both of them 
need to exist. So you could definitely do more to spell out the use-cases here.
> Structural types follow the subtype/supertype relationships of their 
> constituent types. For 

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Colin Barrett via swift-evolution]

> On Jul 30, 2016, at 12:21 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution 
> > wrote:
>> I wrote this a few months ago, but we weren't accepting additive proposals. 
>> Now we're explicitly looking for something like this:
>> 
>> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory 
>> ownership model to Swift is highly desired by systems programmers and folks 
>> who want predictable and deterministic performance (for example, in real 
>> time audio processing code).  More pertinent to the goals of Swift 4, this 
>> feature is important because it fundamentally shapes the ABI.  It informs 
>> code generation for “inout", how low-level “addressors” work in the ABI, 
>> impacts the Swift runtime, and will have a significant impact on the type 
>> system and name mangling. 
> 
> Memory ownership is about something slightly different than this.  In the 
> context of Swift, the model we’re looking for is:
> 
> - You can completely ignore memory ownership features of the language, and 
> get very far into development with Swift.  This is in stark contrast with 
> Rust and Cyclone, which require you to grapple with it up front.  This means 
> that in the Swift context, this will be more of a “power user” feature, 
> instead of essential part of the model.
> 
> - You can choose to use the memory ownership features by adding extra 
> annotations, giving better performance and control over ARC.  Right now we 
> have very limited options for avoiding ARC overhead in critical loops, 
> largely forcing you to drop down to unsafe constructs.  We’d prefer the model 
> to be “you can add more annotations to your code to get better performance, 
> allowing the compiler statically verify correctness instead of dynamically”.

Has any thought been giving to opting in something analogous in the other 
direction—i.e. less performant, but less work for the programer? Specifically, 
I’ve long thought that an annotation opting into a runtime cycle collector (a 
la 
http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf
 
)
 would be very helpful for situations where, as you mention, performance is not 
(currently) critical.

-Colin

> - Memory ownership control is an extremely non-trivial feature, which will 
> probably drive us to add first class move semantics and region types to the 
> language.  This will also call for significant standard library extensions.  
> It will pay for this complexity by making it easy to ignore the complexity if 
> you don’t want it, and by the fact that the standard library and other stuff 
> can go much faster.
> 
> - As a Stage 2 feature, I can imagine an opt-in mode that “forces” the use of 
> these features, for code that wants to guarantee deterministic performance.  
> This is what enables the use of swift in realtime audio applications, for 
> example.
> 
> While some initial brainstorming and scoping has been done in this area, 
> we’re far from having a concrete design.  We have a few folks who are experts 
> at Rust that are helping contribute ideas and experience to this though.  
> 
> If you have more specific questions, feel free to ask about it.
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[Colin Barrett via swift-evolution]

I'm not sure how any of that's relevant to what I said. (I'm on my phone. 
Please excuse any incoherence or typos.) Your module system from the other 
proposal is, like in Haskell, tied to the directory structure of the project, 
which is in my mind an anti-pattern. And I don't believe either SML or OCaml 
have a way to selectively import (open in ML terms), much less do renaming. 
Using ML style modules a bunch has me convinced. Beyond first-class modules, 
the key aspects of ML germane to this proposal in my mind are: qualified import 
by default (module statement) and separating identifier search (open statement) 
from re-exporting (include statement). Local open is also a big deal.

For anyone else in the thread curious about ML modules, my friend Danny wrote 
this up a while ago, it's quite good 
http://jozefg.bitbucket.org/posts/2015-01-08-modules.html

-Colin (via thumbs)

> On Jul 21, 2016, at 2:28 AM, Robert Widmann  wrote:
> 
> This approach in no way rules out that direction and the syntax here was 
> built with a module system in mind.  Agda modules admit the kind of 
> abstraction you’re looking for, but they call them Parameterized Modules and 
> they take after Coq’s sections rather than SML’s module functors.  I can 
> assure you, this proposal has nothing to do with Haskell and everything to do 
> with trying to approach scoping and imports with their mindset.
> 
>> On Jul 20, 2016, at 10:18 PM, Colin Barrett  
>> wrote:
>> 
>> Thanks for writing these up, I found them clear and easy to read.
>> 
>> While I don’t know the precise inspirations, both of these drafts seem more 
>> or less in line with the sorts of modules and importing that’s found in 
>> Haskell. I’d much prefer these facilities not be added to Swift. I would 
>> much rather see Swift develop in the direction of ML and add something like 
>> first-class modules and (module) functors. After writing a lot of both 
>> Haskell and ML family languages, I can say from experience that the 
>> Haskell-style approach is broadly inferior.
>> 
>> I have no idea if first-class modules are on the Core Team’s collective 
>> mind, but it’s what I’d advocate for.
>> 
>> -Colin
>> 
>>> On Jul 20, 2016, at 2:52 PM, Robert Widmann via swift-evolution 
>>>  wrote:
>>> 
>>> Hello all,
>>> 
>>> I’d like to thank the members of the community that have guided the 
>>> revisions of this proposal.  We have decided to heed the advice of the 
>>> community and break down our original proposal on modules and qualified 
>>> imports into source-breaking (qualified imports) and additive (modules) 
>>> proposals.  As qualified imports is the change most suited to Swift 3, we 
>>> are pushing that proposal now as our final draft.
>>> 
>>> It can be had inline with this email, on Github, or as a gist.
>>> 
>>> Thanks,
>>> 
>>> ~Robert Widmann
>>> 
>>> Qualified Imports Revisited
>>> Proposal: SE-
>>> Authors: Robert Widmann, TJ Usiyan
>>> Status: Awaiting review
>>> Review manager: TBD
>>> Introduction
>>> 
>>> We propose a complete overhaul of the qualified imports syntax and 
>>> semantics.
>>> 
>>> Motivation
>>> 
>>> The existing syntax for qualified imports from modules is needlessly 
>>> explicit, does not compose, and has a default semantics that dilutes the 
>>> intended meaning of the very operation itself. Today, a qualified import 
>>> looks something like this
>>> 
>>> import class Foundation.Date
>>> This means that clients of Foundation that wish to see only Date must know 
>>> the exact kind of declaration that identifier is. In addition, though this 
>>> import specifies exactly one class be imported from Foundation, the actual 
>>> semantics mean Swift will recursively open all of Foundation's submodules 
>>> so you can see, and use, every other identifier anyway - and they are not 
>>> filtered from code completion. Qualified imports deserve to be first-class 
>>> in Swift, and that is what we intend to make them with this proposal.
>>> 
>>> Proposed solution
>>> 
>>> The grammar and semantics of qualified imports will change completely with 
>>> the addition of import qualifiers and import directives. We also introduce 
>>> two new contextual keywords: using and hiding, to facilitate fine-grained 
>>> usage of module contents.
>>> 
>>> Detailed design
>>> 
>>> Qualified import syntax will be revised to the following
>>> 
>>> import-decl -> import  <(opt) import-directive-list>
>>> import-path -> 
>>> -> .
>>> import-directive-list -> 
>>>   ->  
>>> import-directive -> using (, ...)
>>>  -> hiding (, ...)
>>> This introduces the concept of an import directive. An import directive is 
>>> a file-local modification of an imported identifier. A directive can be one 
>>> of 2 operations:
>>> 
>>> 1) using: The using directive is followed by a list of identifiers for 
>>> non-member nominal declarations within the 

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[Colin Barrett via swift-evolution]

Thanks for writing these up, I found them clear and easy to read.

While I don’t know the precise inspirations, both of these drafts seem more or 
less in line with the sorts of modules and importing that’s found in Haskell. 
I’d much prefer these facilities not be added to Swift. I would much rather see 
Swift develop in the direction of ML and add something like first-class modules 
and (module) functors. After writing a lot of both Haskell and ML family 
languages, I can say from experience that the Haskell-style approach is broadly 
inferior.

I have no idea if first-class modules are on the Core Team’s collective mind, 
but it’s what I’d advocate for.

-Colin

> On Jul 20, 2016, at 2:52 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> I’d like to thank the members of the community that have guided the revisions 
> of this proposal.  We have decided to heed the advice of the community and 
> break down our original proposal on modules and qualified imports into 
> source-breaking (qualified imports) and additive (modules) proposals.  As 
> qualified imports is the change most suited to Swift 3, we are pushing that 
> proposal now as our final draft.
> 
> It can be had inline with this email, on Github 
> , or as a gist 
> .
> 
> Thanks,
> 
> ~Robert Widmann
> 
> Qualified Imports Revisited
> 
> Proposal: SE- 
> 
> Authors: Robert Widmann , TJ Usiyan 
> 
> Status: Awaiting review
> Review manager: TBD
> 
>  
> Introduction
> 
> We propose a complete overhaul of the qualified imports syntax and semantics.
> 
> 
>  
> Motivation
> 
> The existing syntax for qualified imports from modules is needlessly 
> explicit, does not compose, and has a default semantics that dilutes the 
> intended meaning of the very operation itself. Today, a qualified import 
> looks something like this
> 
> import class Foundation.Date
> This means that clients of Foundation that wish to see only Date must know 
> the exact kind of declaration that identifier is. In addition, though this 
> import specifies exactly one class be imported from Foundation, the actual 
> semantics mean Swift will recursively open all of Foundation's submodules so 
> you can see, and use, every other identifier anyway - and they are not 
> filtered from code completion. Qualified imports deserve to be first-class in 
> Swift, and that is what we intend to make them with this proposal.
> 
> 
>  
> Proposed
>  solution
> 
> The grammar and semantics of qualified imports will change completely with 
> the addition of import qualifiers and import directives. We also introduce 
> two new contextual keywords: using and hiding, to facilitate fine-grained 
> usage of module contents.
> 
> 
>  
> Detailed
>  design
> 
> Qualified import syntax will be revised to the following
> 
> import-decl -> import  <(opt) import-directive-list>
> import-path -> 
> -> .
> import-directive-list -> 
>   ->  
> import-directive -> using (, ...)
>  -> hiding (, ...)
> This introduces the concept of an import directive. An import directive is a 
> file-local modification of an imported identifier. A directive can be one of 
> 2 operations:
> 
> 1) using: The using directive is followed by a list of identifiers for 
> non-member nominal declarations within the imported module that should be 
> exposed to this file. 
> 
> // The only visible parts of Foundation in this file are 
> // Foundation.Date, Foundation.DateFormatter, and Foundation.DateComponents
> //
> // Previously, this was
> // import class Foundation.Date
> // import class Foundation.DateFormatter
> // import class Foundation.DateComponents
> import Foundation using (Date, DateFormatter, DateComponents)
> 2) hiding: The hiding directive is followed by a list of identifiers for 
> non-member nominal declarations within the imported module that should be 
> hidden from this file.
> 
> // Imports all of Foundation except `Date`
> import Foundation hiding (Date)
> As today, all hidden identifiers do not hide the type, they merely hide that 
> type’s members and its declaration. For example, this means values of hidden 
> types are still allowed. Unlike the existing implementation, using their 
> members is forbidden.
> 
> // Imports `DateFormatter` but the declaration of `Date` is hidden.
> import Foundation using (DateFormatter)
> 
> var d = 

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

[Colin Barrett via swift-evolution]

There's no need for this, that's what I was trying to get across. It's (likely) 
a special case in the grammar right now. If we eliminate Any<>, from the point 
of view of syntax, both Any and Any are just a built in  type and 
normal application of generic arguments (to a built in type).

-Colin (via thumbs)

> On May 19, 2016, at 1:58 AM, Austin Zheng  wrote:
> 
> - 'Any<>' should be allowed. You can currently use 'protocol<>' in your code 
> instead of 'Any'.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

[Colin Barrett via swift-evolution]

Thanks Matthew. Personally I would really like to see an analysis of the 
tradeoffs therein covered in the proposal in some way.

-Colin (via thumbs)

> On May 4, 2016, at 8:23 PM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
> 
>>> On May 4, 2016, at 6:56 PM, Colin Barrett via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Swift numeric types all currently have a family of conversion initializers. 
>>> In many use cases they leave a lot to be desired. Initializing an integer 
>>> type with a floating point value will truncate any fractional portion of 
>>> the number. Initializing with an out-of-range value traps.
>> 
>> 
>> Have you considered whether it makes sense to keep these around? Maybe the 
>> failable ones should be the default, and give the other ones a more 
>> descriptive 1st argument label.
> 
> That’s a good question.  It might be a good idea, but I wanted to keep this 
> proposal small and non-breaking to maximize chances of acceptance.  I would 
> support that change to the proposal if the core team was interested in going 
> that direction.
> 
>> 
>> -Colin
>> ___
>> 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-0080: Failable Numeric Conversion Initializers

[Colin Barrett via swift-evolution]

> Swift numeric types all currently have a family of conversion initializers. 
> In many use cases they leave a lot to be desired. Initializing an integer 
> type with a floating point value will truncate any fractional portion of the 
> number. Initializing with an out-of-range value traps.


Have you considered whether it makes sense to keep these around? Maybe the 
failable ones should be the default, and give the other ones a more descriptive 
1st argument label.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

[Colin Barrett via swift-evolution]

Okay, great. That makes sense, thanks for clarifying Chris. 

-Colin (via thumbs)

> On Mar 25, 2016, at 12:35 AM, Chris Lattner <clatt...@apple.com> wrote:
> 
> 
>> On Mar 24, 2016, at 11:09 AM, Colin Barrett via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> The proposal is unclear to me in what it is, er, proposing. The motivation 
>> section speaks about allow `let` to be used as argument label, but the 
>> proposed solution says that func foo(let x: Int) { … } would be an error. 
>> That seems like it’s contrary to the motivations of the proposal.
> 
> The proposal is simply that "func foo(let x: Int) { … }” be disallowed, since 
> it is redundant with "func foo(x: Int) { … }”.  In terms of taking back “let” 
> as a parameter label, this only makes sense in the future, when we give up on 
> migration of the former into the later.
> 
> At that point, let could conceivably be used as an external label, as in 
> "foo(let: 42)”.  This would make the language simpler and more consistent, 
> since we allow other keywords there.
> 
> -Chris
> 
>> 
>> -Colin
>> 
>>> On Mar 24, 2016, at 2:00 PM, Chris Lattner <clatt...@apple.com> wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "Remove explicit use of let from Function Parameters" begins 
>>> now and runs through March 27th. The proposal is available here:
>>> 
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at:
>>>https://lists.swift.org/mailman/listinfo/swift-evolution
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>>* What is your evaluation of the proposal?
>>>* Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>>* Does this proposal fit well with the feel and direction of Swift?
>>>* If you have you used other languages or libraries with a similar 
>>> feature, how do you feel that this proposal compares to those?
>>>* How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at
>>> 
>>>https://github.com/apple/swift-evolution/blob/master/process.md
>>> 
>>> Thank you,
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 
>>> 
>>> ___
>>> swift-evolution-announce mailing list
>>> swift-evolution-annou...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

[Colin Barrett via swift-evolution]

On Mar 24, 2016, at 5:55 PM, Max Howell  wrote:

>> Thanks for sending out this proposal. I admit I’m somewhat ignorant of the 
>> current state of SwiftPM so feel free to point me at existing resources if 
>> I’m missing basic things.
>> 
>> You don’t cover it in your proposal, but does this mean pkg-config is now a 
>> dependency for SwiftPM? I may be mistaken but it doesn’t seem as though 
>> pkg-config is installed on the base OS X system. (This leads me to assume 
>> it’s an optional dependency.)
> 
> This is a good point, I’ll revise the proposal.
> 
> My intentions were: if available, use it, if not, then things may not build. 
> Long term we could parse pkg-config files ourselves since the format is very 
> basic which would be preferable since “your package graph *may* or *may not* 
> build” is hardly fun

Great! Myself, I would just parse the pc files straight away. Avoiding 
dependencies seems  highly desirable for something this low in the stack.

>> Your proposal suggests the set of supported package mangers will be closed. 
>> What about folks using new, or non-standard package managers?
> 
> They can add their package manager to the supported list via a Pull Request.

This is a surprising answer! Just to be clear―what functionality, specifically, 
is this enabling?

>> What about packages that are installed system-wide without a package manager 
>> (e.g. with ./configure && make && make install)? 
> 
> Such packages should come with a .pc file.
> 
>> This may be covered elsewhere, but about the case of a C package that is 
>> normally system-wide but is currently being hacked on by the user? (For 
>> example to while debugging it, or writing bindings for it.)
> 
> There is no convenient way to do this at this time, but proposals are 
> welcome. It *is* possible currently, you can make a local module map package 
> that encapsulates the C library, or if it is simple enough our C-target 
> support may be sufficient

No proposal here, but this is more common than you'd think―it merits at least 
an FAQ in the final proposal.

Thanks Max!
-Colin

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Colin Barrett via swift-evolution]

> On Mar 24, 2016, at 1:13 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> How about we continue this trend, and follow other existing Swift keywords 
> that merge two lowercase words (associatedtype, typealias, etc), and use:
> 
>   public
>   moduleprivate
>   fileprivate
>   private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the 
> submodule name/path in parens: private(foo.bar.baz) or 
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> natural than putting keywords in parens.

+1. It also has the advantage of getting rid of the confusing distinction 
between “private” and “internal”—which is backwards from the usual 
“API/SPI/IPI” terminology.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

[Colin Barrett via swift-evolution]

The proposal is unclear to me in what it is, er, proposing. The motivation 
section speaks about allow `let` to be used as argument label, but the proposed 
solution says that func foo(let x: Int) { … } would be an error. That seems 
like it’s contrary to the motivations of the proposal.

-Colin

> On Mar 24, 2016, at 2:00 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "Remove explicit use of let from Function Parameters" begins 
> now and runs through March 27th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> 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] Proposal: Rewrite Swift compiler in swift to get ideas for further language evolution.

[Colin Barrett via swift-evolution]

> On Dec 19, 2015, at 7:32 PM, Amir Michail  wrote:
> 
> 
>> On Dec 19, 2015, at 7:21 PM, Colin Barrett  
>> wrote:
>> 
>> I’d recommend you read 
>> http://tratt.net/laurie/blog/entries/the_bootstrapped_compiler_and_the_damage_done,
>>  which has a number of rebuttals to what you’ve said below.
>> 
> 
> That’s an interesting article but it doesn’t address the issue of whether 
> compiler code is more like normal programming than compiler standard library 
> code.

Perhaps I don’t understand what you mean, but the article gives two good 
reasons why compiler code is special. The first reason is that we understand a 
lot about how to design a compiler, much more than we understand about how to 
design other types of programs. The second follows:

> [C]ompilers are an atypical class of program. In essence, a compiler is a 
> simple batch pipeline process. A program is read in and translated to a tree; 
> a series of tree transformations are applied; and eventually one of those 
> trees is saved out as some sort of binary data (e.g. machine code or 
> bytecode). Most of the intermediate tree transformations calculate a 
> relatively simple bit of information about the program and create a slightly 
> modified tree based on it. A few calculations crop up time and time again, 
> such as: maps from variables to scopes or types; and stacks to determine 
> closures. Significantly, and unlike most programs in the real world, there is 
> no interaction with users: the compiler knows all it needs about the outside 
> world from the moment it is called.

Personally, I think the main reason not to rewrite the Swift compiler is that 
it would be a distraction from improving the Swift language and other 
associated tools.

-Colin

>>> On Dec 19, 2015, at 4:41 PM, Amir Michail via swift-evolution 
>>>  wrote:
>>> 
>>> Compiler code is probably more typical of what most programmers write than 
>>> library code and so would be ideal for suggesting further language 
>>> evolution ideas.
>>> ___
>>> 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