Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Ben Rimmington via swift-evolution]

An alternative is a special #knownCases(of:) literal.

Its value is an array literal of the enum cases known at compile time.

This could also work with enums imported from Objective-C.

-- Ben

> On 10 Jan 2018, at 22:54, Jordan Rose wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>  
> ]
> 
> I think this is generally reasonable, and none of the names offend me enough 
> to weigh in on that discussion. I do think it's a little weird that @objc 
> enums defined in Swift cannot conform to ValueEnumerable, just because 
> imported enums won't. (But especially while knee-deep in SE-0192, I think 
> it's correct that imported enums won't. The exception could be C enums marked 
> `enum_extensibility(closed)`, but I'm not convinced we need that yet.)
> 
> The biggest problem I have is unavailable cases. An unavailable case must not 
> be instantiated—consider an enum where some cases are only available on iOS 
> and not macOS. (I bet we optimize based on this, which makes it all the more 
> important to get right.)
> 
> I think you should explicitly call out that the derived implementation only 
> kicks in when ValueEnumerable is declared on the enum itself, not an 
> extension. Or if that's not the case, it should be limited to extensions in 
> the same module as the enum. (You could add "unless the enum is '@frozen'", 
> but that's not really necessary.)
> 
> I don't think this should be implemented with a run-time function; 
> compile-time code generation makes more sense to me. But that's an 
> implementation detail; it doesn't change the language surface.
> 
> Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Ben Rimmington via swift-evolution]

Something like this was attempted (and reverted) for Swift 3:







Is it now possible to `import PlaygroundSupport` outside of a playground?

-- Ben

> On 9 Jan 2018, at 23:19, Connor Wakamo wrote:
> 
> Good afternoon,
> 
> In preparation for ABI stability, I’ve reviewed the API exposed by the 
> standard library for providing customized “quick looks” in playgrounds. This 
> is exposed as the PlaygroundQuickLook enum and the 
> CustomPlaygroundQuickLookable protocol. The PlaygroundQuickLook has a handful 
> of issues:
> 
>   - It hard-codes the list of supported types in the standard library, 
> meaning that PlaygroundLogger/IDEs cannot gain support for new types without 
> standard library changes (including swift-evolution review)
>   - The cases of the enum are poorly typed: there are cases like `.view` 
> and `.color` which take NS/UIView or NS/UIColor instances, respectively, but 
> since they’re in the standard library, they have to be typed as taking `Any` 
> instead
>   - The names of some of these enum cases do not seem to match Swift 
> naming conventions)
> 
> To that end, I am proposing the following:
> 
>   - Deprecate PlaygroundQuickLook and CustomPlaygroundQuickLookable in 
> Swift 4.1 (including in the Swift 3 compatibility mode)
>   - Remove PlaygroundQuickLook and CustomPlaygroundQuickLookable in Swift 
> 5 to avoid including them in the stable ABI (this affects the compatibility 
> modes, too)
>   - Introduce a new protocol, CustomPlaygroundRepresentable, in the 
> PlaygroundSupport library in Swift 4.1:
> 
>   protocol CustomPlaygroundRepresentable {
>   /// Returns an alternate object or value which should 
> stand in for the receiver in playground logging, or nil if the receiver’s 
> default representation is preferred.
>   var playgroundRepresentation: Any? { get }
>   }
> 
>   - Update the PlaygroundLogger library in Swift 4.1 to support both 
> CustomPlaygroundRepresentable and 
> PlaygroundQuickLook/CustomPlaygroundQuickLookable
>   - Provide a compatibility shim library which preserves 
> PlaygroundQuickLook and CustomPlaygroundQuickLookable as deprecated in Swift 
> 3/4 and unavailable in Swift 5, but only in playgrounds (including in the 
> auxiliary source files stored inside a playground)
> 
> I’ve put a full proposal below. Please let me know what you think of this 
> proposal; I’d like to get some feedback before taking this through the review 
> process, but I’ll need to get that quickly so I can get it under review soon 
> as this is targeted at Swift 4.1.
> 
> Thanks,
> Connor
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] DynamicMemberLookup proposal: status update

[Ben Rimmington via swift-evolution]

Have you seen John Holdsworth's experiments?


-- Ben

> On 4 Jan 2018, at 20:52, Chris Lattner wrote:
> 
> Hi everyone,
> 
> With the holidays and many other things behind us, the core team had a chance 
> to talk about python interop + the dynamic member lookup proposal recently.
> 
> Here’s where things stand: we specifically discussed whether a 
> counter-proposal of using “automatically generated wrappers” or “foreign 
> classes” to solve the problem would be better.  After discussion, the 
> conclusion is no: the best approach appears to be 
> DynamicMemberLookup/DynamicCallable or something similar in spirit to them.  
> As such, I’ll be dusting off the proposal and we’ll eventually run it.
> 
> For transparency, I’m attaching the analysis below of what a wrapper facility 
> could look like, and why it doesn’t work very well for Python interop.  I 
> appologize in advance that this is sort of train-of-thought and not a well 
> written doc. 
> 
> That said, it would be really great to get tighter integration between Swift 
> and SwiftPM for other purposes!  I don’t have time to push this forward in 
> the short term though, but if someone was interested in pushing it forward, 
> many people would love to see it discussed seriously.
> 
> -Chris

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

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

[Ben Rimmington via swift-evolution]

> On 3 Jan 2018, at 02:07, Jordan Rose wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>  
> ]
> 
> Whew! Thanks for your feedback, everyone. On the lighter side of 
> feedback—naming things—it seems that most people seem to like '@frozen', and 
> that does in fact have the connotations we want it to have. I like it too.

Should there be a new Clang attribute for "frozen" enums? Then the existing 
`__attribute__((enum_extensibility(closed)))` would only prevent "private" 
cases (and not future "public" cases).



> More seriously, this discussion has convinced me that it's worth including 
> what the proposal discusses as a 'future' case. The key point that swayed me 
> is that this can produce a warning when the switch is missing a case rather 
> than an error, which both provides the necessary compiler feedback to update 
> your code and allows your dependencies to continue compiling when you update 
> to a newer SDK. I know people on both sides won't be 100% satisfied with 
> this, but does it seem like a reasonable compromise?
> 
> The next question is how to spell it. I'm leaning towards `unexpected case:`, 
> which (a) is backwards-compatible, and (b) also handles "private cases", 
> either the fake kind that you can do in C (as described in the proposal), or 
> some real feature we might add to Swift some day. `unknown case:` isn't bad 
> either.

You might end up with `case .unknown:` and `unknown case:` in the same switch.

e.g. 

```
switch mediaType {
case .image, .video, .audio:
break
case .unknown:
break
unknown case:
break
}
```

-- Ben

___
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

[Ben Rimmington via swift-evolution]

> On 21 Dec 2017, at 03:32, John McCall wrote:
> 
>> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote:
>> 
>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote:
>>> 
>>> • What is your evaluation of the proposal?
>> 
>> I am pleased with the broad strokes of this design. I have quibbles with 
>> three areas:
>> 
>> 1. The `@exhaustive` attribute may be confusing because the term doesn't 
>> suggest versioning. My best alternative suggestion is `@frozen`, which 
>> matches existing programming terminology: something that has been frozen 
>> will not be changed in the future.
> 
> I rather like @frozen.  We could use that across language features, so that 
> we don't end up with a keyword per kind of declaration.

Could this also be used on functions to make them inlinable?
i.e. The body of the function has been frozen.

```
@frozen
public func a()

@available(*, frozen)
public func b()

@available(swift, introduced: 4.1, frozen: 5.0)
public func c()

```




-- Ben

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

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

[Ben Rimmington via swift-evolution]

[Forum] merging multiple staged accounts


[Forum] importing names with non-Latin characters


-- Ben

> On 12 Dec 2017, at 06:41, Ben Rimmington wrote:
> 
> When claiming a staged account, can the username be changed?
> e.g. Having the same "@username" on GitHub and Swift Forums.
> 
> Will people with multiple accounts be able to merge them?
> 
> 
> Names with non-Latin characters are not imported correctly:
> 
> e.g. StringTransform("Any-Latin; Latin-ASCII; Any-Title")
> 
> -- Ben

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

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

[Ben Rimmington via swift-evolution]

When claiming a staged account, can the username be changed?
e.g. Having the same "@username" on GitHub and Swift Forums.

Will people with multiple accounts be able to merge them?


Names with non-Latin characters are not imported correctly:

e.g. StringTransform("Any-Latin; Latin-ASCII; Any-Title")

-- Ben

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Ben Rimmington via swift-evolution]

> Chris Lattner wrote:
> 
>   let np = Python.import("numpy")
>   let b = np^.array^([6, 7, 8])
>   let y =  np^.arange^(24)^.reshape^(2, 3, 4)
>   
>   let a = np^.ones^(3, dtype: np^.int32)
>   let b = np^.linspace^(0, pi, 3)
>   let c = a+^b
>   let d = np^.exp^(c)

You could require `throws` on `subscript(dynamicMember:)` APIs.

"Throwing Properties and Subscripts proposal by brentdax"


let np = Python.import("numpy")
let x = try! np.array([6, 7, 8])
let y = try! np.arange(24).reshape(2, 3, 4)

let a = try! np.ones(3, dtype: np.int32)
let b = try! np.linspace(0, pi, 3)
let c = try! a+b
let d = try! np.exp(c)

If you allow dynamic member lookup on stdlib types:

Double.pi.significant
 ^
ERROR: subscript can throw, but it is not marked with 'try'
NOTE: did you mean 'significand'?

An implementation could fail by throwing an error or returning `nil`.
For example, JSValue/JSON member lookup could allow optional chaining.
But trying to invoke a non-callable JSValue could throw a TypeError.

-- Ben

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Ben Rimmington via swift-evolution]

> On 28 Nov 2017, at 22:06, Jean-Daniel  wrote:
> 
> While I perfectly understand why subscript is the best way to represent 
> dynamic property, I don’t get how it help to abuse it to implement dynamic 
> methods. Methods are not l-value, so why do you want to use a subscript for 
> them ?

First, I tried overloading `subscript(dynamicMember:)` by return type.

subscript(dynamicMember name: String) -> (_ arguments: Any...) -> JSValue
subscript(dynamicMember name: String) -> JSValue

It allows for method calls without the DynamicCallable proposal.

context[dynamicMember: "Math"][dynamicMember: "pow"](2, 53)
//-> 9007199254740992

context[dynamicMember: "Math"][dynamicMember: "PI"] as JSValue
//-> 3.1415926535897931

context[dynamicMember: "Math"][dynamicMember: "PI"]
//ERROR: Ambiguous use of 'subscript(dynamicMember:)'

This evolved into the differently labelled subscripts,
to avoid having to disambiguate by return type.

But you're right, a function might be better than a subscript.

-- Ben

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Ben Rimmington via swift-evolution]

I suggest using different subscripts for function/method calls and properties:

* `value(...)`  ==> `value[dynamicFunction: ""](...)`
* `value.name(...)` ==> `value[dynamicFunction: "name"](...)`
* `value.name`  ==> `value[dynamicProperty: "name"]`

Dynamic callable types have an unnamed method.
Dynamic argument labels are always allowed (but can be ignored).
For example, the labels of `Date.UTC` below are not passed to JavaScript.

//===--===//
//  JavaScriptCore.playground
//===--===//

import Foundation
import JavaScriptCore

typealias Arguments = DictionaryLiteral

extension JSContext {

subscript(dynamicFunction name: String) -> (_ arguments: Arguments) -> 
JSValue {
return globalObject[dynamicFunction: name]
}

subscript(dynamicProperty name: String) -> JSValue {
get {
return globalObject[dynamicProperty: name]
}
set {
globalObject[dynamicProperty: name] = newValue
}
}
}

extension JSValue {

subscript(dynamicFunction name: String) -> (_ arguments: Arguments) -> 
JSValue {
return { arguments in
let argumentValues = arguments.map({ $0.value })
if name.isEmpty {
return self.call(withArguments: argumentValues)
} else if name == "new" {
return self.construct(withArguments: argumentValues)
} else {
return self.invokeMethod(name, withArguments: argumentValues)
}
}
}

subscript(dynamicProperty name: String) -> JSValue {
get {
return forProperty(name)
}
set {
setValue(newValue, forProperty: name)
}
}
}

//===--===//
//  Examples
//===--===//

let context = JSContext()!

//: ```
//: context.isNaN(Double.nan)
//: ```
context[dynamicFunction: "isNaN"](["": Double.nan])

//: ```
//: context.Math.PI
//: ```
context[dynamicProperty: "Math"][dynamicProperty: "PI"]

//: ```
//: context.Math.PI.toFixed(5)
//: ```
context[dynamicProperty: "Math"][dynamicProperty: "PI"][dynamicFunction: 
"toFixed"](["": 5])

//: ```
//: context.Math.pow(2, 53)
//: ```
context[dynamicProperty: "Math"][dynamicFunction: "pow"](["": 2, "": 53])

//: ```
//: let time = context.Date.UTC(
//: year: , month: 11, day: 31,
//: hour: 23, minute: 59, second: 59, millisecond: 999)
//: ```
let time = context[dynamicProperty: "Date"][dynamicFunction: "UTC"]([
"year": , "month": 11, "day": 31,
"hour": 23, "minute": 59, "second": 59, "millisecond": 999])

//: ```
//: let date = context.Date.new(time)
//: ```
let date = context[dynamicProperty: "Date"][dynamicFunction: "new"](["": time])

//: ```
//: date.toISOString()
//: ```
date[dynamicFunction: "toISOString"]([:])


> On 27 Nov 2017, at 06:04, Chris Lattner wrote:
> 
> I’d like to formally propose the inclusion of user-defined dynamic member 
> lookup types.
> 
> Here is my latest draft of the proposal:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> https://github.com/apple/swift-evolution/pull/768
> 
> An implementation of this design is available here:
> https://github.com/apple/swift/pull/13076
> 
> The implementation is straight-forward and (IMO) non-invasive in the compiler.
> 
> -Chris

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

Re: [swift-evolution] [Pitch #2] Introduce user-defined dynamically "callable" types

[Ben Rimmington via swift-evolution]

DynamicCallable.md


DynamicMemberLookup.md


JavaScriptCore.JSValue


If the JSValue class implements these protocols, 
how will it choose to invoke itself?

1. `call(withArguments:)`
2. `construct(withArguments:)`
3. `invokeMethod(_:withArguments:)`

import Foundation
import JavaScriptCore

let context = JSContext()!

let dateClass = context.objectForKeyedSubscript("Date")!
assert(dateClass.isObject)

// 1. `const dateString = Date()`
let dateString = dateClass.call(withArguments: [])!
assert(dateString.isString)

// 2. `const dateObject = new Date()`
let dateObject = dateClass.construct(withArguments: [])!
assert(dateObject.isObject)

// 3a. `const dateNumberA = Date.now()`
let dateNumberA = dateClass.invokeMethod("now", withArguments: [])!
assert(dateNumberA.isNumber)

// 3b. `const dateNumberB = dateObject.valueOf()`
let dateNumberB = dateObject.invokeMethod("valueOf", withArguments: [])!
assert(dateNumberB.isNumber)

-- Ben

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

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

[Ben Rimmington via swift-evolution]

> On 21 Nov 2017, at 00:17, Jonathan Hull wrote:
> 
> I would also like to see something shorter than targetEnvironment(), but it 
> is somewhat infrequently used, so it isn’t that big a deal.  It is just 
> compared to os() and arch(), this is kind of a beast.  It is a power user 
> thing, so maybe something like ‘env()’ would work?  I normally try to avoid 
> abbreviations, but we have arch() as precedent.  The word ‘Simulator’ should 
> be what stands out...

Xcode uses `destination`:

e.g. 

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

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

[Ben Rimmington via swift-evolution]

> On 8 Nov 2017, at 18:57, Erica Sadun wrote:
> 
> Colocation of docs with the material they document is valuable to me and I 
> presume anyone updating code. If anything, it would be nice if Xcode provided 
> a show/hide doc headers toggle though.

[Xcode 9.1]

Editor > Code Folding > Fold Comment Blocks

Editor > Code Folding > Fold Methods & Functions
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [draft] Target environment platform condition

[Ben Rimmington via swift-evolution]

Could this be an extra parameter for the os() platform condition?

#if os(iOS, simulator)

#if os(Android, emulator)

-- Ben

> On 25 Oct 2017, at 04:05, Graydon Hoare wrote:
> 
> Hi,
> 
> I'd like to propose a variant of a very minor, additive proposal Erica Sadun 
> posted last year, that cleans up a slightly messy idiomatic use of 
> conditional compilation in libraries. The effects should be quite limited; 
> I'd call it a "standard library" addition except that the repertoire of 
> compiler-control statements isn't strictly part of the stdlib.
> 
> Proposal is here: 
> https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d
> 
> Implementation (minus fixits) is here: 
> https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982
> 
> Feedback appreciated,
> 
> -Graydon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Ben Rimmington via swift-evolution]

> On 14 Sep 2017, at 15:31, Haravikk wrote:
> 
>> On 14 Sep 2017, at 02:12, Xiaodi Wu wrote:
>> 
>>> On Wed, Sep 13, 2017 at 09:13 Haravikk wrote:
>>> 
>>> I mean because not once have you summarised what these alleged 
>>> "considerations" were; if they exist then you should be able do so, yet all 
>>> I am hearing is "it was considered", which frankly is not an argument at 
>>> all as it is entirely without substance.
>> 
>> Of course it is not an argument at all. It is a factual statement. The 
>> objections which you mentioned were also mentioned prior to a decision about 
>> SE-0185. The community and the core team had an opportunity to view those 
>> objections. After that time, a decision was made, having considered all the 
>> stated pros and cons which included the ones that you are now repeating. 
>> What "considerations" are you looking for?
> 
> Ones with proof that they were ever made! Once again you are stating that 
> these issues were "considered", yet you show not a single shred of proof that 
> that was the case. You're asking me to take you at your word but I have no 
> reason to trust that the problem has been as carefully considered as you 
> claim.
> I was involved in one such discussion and the response from the core team was 
> frankly pitiful; they did not provide any justification whatsoever.

Chris Lattner already said that the core team discussed your concerns:





The original idea was for most types to be *implicitly* equatable and hashable:



The accepted proposal, with *explicit* declaration of conformance, is a good 
compromise.

Instead of discussing hypothetical issues with SE-0185, we can wait for Swift 
4.1 beta.

-- Ben

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

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Ben Rimmington via swift-evolution]

> On 5 Sep 2017, at 21:02, Haravikk wrote:
> 
> Anyway, this is basically just a rough dump of the ideas for how the 
> synthesised Codable, Equatable and Hashable behaviours (and anything else 
> anyone can think of) should be changed before Swift 4 is released.

Swift 4, Xcode 9 and iOS 11 will **probably** be released on September 12:



All previous major versions have also been released in mid-September:



There isn't enough time to propose, review and implement @synthetic (AFAIK).

-- Ben

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

Re: [swift-evolution] [Concurrency] async/await + actors

[Ben Rimmington via swift-evolution]

Re: 

Chris Lattner recently commented in  
that the prototype could use  support.

In one of the CppCon videos, Gor Nishanov said that C++ coroutines won't have 
an `async` keyword, and will be compatible with function pointers in C and C++.

* 


* 

* 


I couldn't find the reason for this decision; does anyone here know why C++ 
coroutines don't need an `async` keyword?

And/or why do Swift coroutines need the `async` keyword? Does it imply a hidden 
parameter, like the `throws` keyword?

-- Ben

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

Re: [swift-evolution] [Pitch] Adding accessibility specifiers to @available

[Ben Rimmington via swift-evolution]

> On 22 Aug 2017, at 17:08, Tony Allevato wrote:
> 
> A few months ago (before Swift 5 chatter started), I pitched an idea to 
> improve the use of @availability in third-party code by eliminating 
> deprecation warnings in same-file references. We had some good discussion 
> there about who needed same-file deprecation vs. same-module deprecation and 
> so forth, and I was convinced that a better approach would be to allow 
> @available to be enforced based on accessibility.

FYI

Excise "Accessibility" from the compiler:


> @jrose-apple (Jordan Rose) wrote:
> 
> "Accessibility" has a different meaning for app developers, so we've already 
> deliberately excised it from our diagnostics in favor of terms like "access 
> control" and "access level". Do the same in the compiler now that we aren't 
> constantly pulling things into the release branch.
> 
> (This isn't exactly important, but we might as well clean it up.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Ben Rimmington via swift-evolution]

## What is your evaluation of the proposal? ##

+1

When `Codable` can be synthesized in a same-file extension, the same should 
hopefully be possible with `Equatable` and `Hashable`.

"We can relax this restriction soon; it will just require some 
additional implementation that's not ready yet."


An empty same-file extension will be sufficient to opt-in, so `AutoEquatable` 
and `AutoHashable` aren't necessary.

extension Token: Hashable {}

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

Yes, eliminating boilerplate and bug-prone code is a worthwhile contribution.

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

Yes, it follows the existing rules for `Codable` synthesis.

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

A quick reading.

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

Re: [swift-evolution] Swift 5: start your engines

[Ben Rimmington via swift-evolution]

> On 9 Aug 2017, at 07:29, Jonathan Hull wrote:
> 
> Would it be possible to get a series of tutorials on how the systems that 
> make up Swift generally work?  In other words, what are the pieces and how do 
> they fit together?

Slava Pestov wrote a couple of articles last year:





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

Re: [swift-evolution] [idea] errors in properties

[Ben Rimmington via swift-evolution]

Brent Royal-Gordon has written a draft proposal:



> On 25 Jul 2017, at 21:58, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> This sounds like a challenge 🙂 
> But seriously, seems like straight-up implementing the feature and then 
> wondering whether or not the pull request will be merged in or rejected is an 
> unnecessary gamble, which is why swift-evolution exists.
> Haven’t anyone tried to make a proposal for this?
> I’d gladly look into implementing it myself if I new for sure that my efforts 
> wouldn’t be wasted.
> 
>> On Jul 25, 2017, at 11:55 PM, Xiaodi Wu > > wrote:
>> 
>> There have been a number of discussions on the list in this—Google finds a 
>> number of these with a search “swift throwing properties 
>> site:lists.swift.org ”.
>> 
>> The “tldr” seems to be that it’s not supported because no one has written 
>> code to support it yet.
>> On Tue, Jul 25, 2017 at 15:29 Gor Gyolchanyan via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> I’ll just cut to the chase:
>> Why is throwing from get, set, willSet and didSet disallowed?
>> 
>> var login: String {
>>  willSet throws {
>>  guard newValue.count > 5 else {
>>  throw LoginError.loginTooSmall
>>  }
>>  }
>> }
>> 
>> try login = “JebediahKerman” // totally fine
>> try login = “Bob” // throws `LoginError.loginTooSmall`
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Extending [at]autoclosure

[Ben Rimmington via swift-evolution]

> On 24 Jun 2017, at 17:10, Adrian Zubarev wrote:
> 
> 2. Make @autoclosure only wrap when necessary:
> 
> func bar(_ test: @autoclosure () -> Int) {
> print(test())
> }
> 
> let test = { 42 }
> 
> // function produces expected type 'Int'; did you mean to call it with '()'?
> bar(test)

Note that you can forward an autoclosure to another function:
Welcome to Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42).
  1> func foo(_ test: @autoclosure () -> Int) {
  2. print(#function, test())
  3. }
  4. 
  5. func bar(_ test: @autoclosure () -> Int) {
  6. foo(test)
  7. }
  8. 
  9. func baz(_ test: @autoclosure () -> Int) {
 10. bar(test)
 11. }
 12. 
 13. baz(42)
foo 42
 14> 

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

Re: [swift-evolution] Integers and their protocols

[Ben Rimmington via swift-evolution]

Re: 


There are also some commented-out requirements, which were accepted for SE-0067.

(One requirement is obsoleted by the Numeric protocol).

Can these be implemented yet, based on your experience?

FloatingPoint
-



>   /*  TODO: Implement the following APIs once a revised integer protocol is
>   introduced that allows for them to be implemented. In particular, we
>   need to have an "index of most significant bit" operation and "get
>   absolute value as unsigned type" operation on the Integer protocol.
> 
>   /// Creates the closest representable value to the given integer.
>   ///
>   /// - Parameter value: The integer to represent as a floating-point value.
>   init(_ value: Source)
> 
>   /// Creates a value that exactly represents the given integer.
>   ///
>   /// If the given integer is outside the representable range of the type, the
>   /// result is `nil`.
>   ///
>   /// - Parameter value: The integer to represent as a floating-point value.
>   init?(exactly value: Source)
>   */

BinaryFloatingPoint
---



>   /*  TODO: Implement these once it becomes possible to do so (requires 
> revised
>   Integer protocol).
>   /// Creates a new instance from the given value, rounded to the closest
>   /// possible representation.
>   ///
>   /// - Parameter value: A floating-point value.
>   init(_ value: Source)
> 
>   /// Creates a new instance equivalent to the exact given value.
>   ///
>   /// If the value you pass as `value` can't be represented exactly, the 
> result
>   /// of this initializer is `nil`.
>   ///
>   /// - Parameter value: A floating-point value to represent.
>   init?(exactly value: Source)
>   */

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

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

[Ben Rimmington via swift-evolution]

The new `JSONSerialization.WritingOptions.sortedKeys` option was mentioned at 
WWDC.

"What's New in Cocoa" [33:03 ... 33:33]




When the `sortedKeys` option is available, can it be used **by default** in the 
`JSONEncoder`?

Otherwise, can the `JSONEncoder.OutputFormatting` enum have extra cases?

case compact
case compactWithSortedKeys
case prettyPrinted
case prettyPrintedWithSortedKeys



-- Ben

> On 16 Mar 2017, at 22:47, Itai Ferber  wrote:
> 
> The sorted order of keys is an implementation detail of 
> PropertyListSerialization which JSONSerialization does not share.
> This would require a change in JSONSerialization, which is possible, but out 
> of scope for this work specifically. It would have to go through review.
> 
> [FWIW, the key ordering isn’t changing at random; JSONSerialization writes 
> keys in the order that it receives them (sorted in the order that 
> NSDictionary stores them, based on hash). If you want this to not interfere 
> with your Git repo (on a more immediate timescale), you can probably do 
> something like adding a pre-commit Git hook to lint the file as needed. But I 
> digress, this is totally off-topic.]
> 
>> On 16 Mar 2017, at 14:57, Ben Rimmington wrote:
>> 
>> Sorry, I actually meant that keys would be ordered **alphabetically** (as 
>> they are with PropertyListSerialization).
>> 
>> I'm storing output from JSONSerialization in a git repository, and when I 
>> add/remove a single key-value the entire file changes, due to keys being 
>> reordered (seemingly at random).
>> 
>> -- Ben
>> 
>>> Itai Ferber wrote:
>>> 
>>> By stable ordering, you mean dictionaries with keys being output in the 
>>> order that they were encoded?
>>> Potentially, but this would require additional work as neither Swift 
>>> dictionaries nor NSMutableDictionary support this (reasonable seeing as 
>>> dictionaries are by definition not sorted), and the current implementation 
>>> uses JSONSerialization as the concrete serializer. Certainly not 
>>> impossible, though.
>>> 
 On 16 Mar 2017, at 8:49, Ben Rimmington wrote:
 
 
 
 Could the `JSONEncoder.OutputFormatting.prettyPrinted` case include the 
 **stable ordering** of keys?
 
 -- Ben
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #error

[Ben Rimmington via swift-evolution]

> On 11 Jun 2017, at 19:15, Beta wrote:
> 
> A proposal and implementation of #warning exist.  It has been judged out of 
> scope for Swift 3 and Swift 4 phase 2. 
> 
> https://github.com/apple/swift-evolution/pull/353

See also "[Pitch] #warning" in the mailing lists:

 (35)


 (11)


 (24)

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

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

[Ben Rimmington via swift-evolution]

I assumed that Swift 3 mode would be the default, so that existing 
`#!/usr/bin/swift` scripts continue to work.

-- Ben

> On 3 Jun 2017, at 23:47, Jens Persson  wrote:
> 
> Yes of course, try my demonstration code yourself.
> (In the current dev snapshots, -swift-version 4 is the default and 
> -swift-version 3 is what you need to set if you want 3 compability)
> 
>> On Sun, Jun 4, 2017 at 12:37 AM, Ben Rimmington  
>> wrote:
>> 
>> Are you using the Swift 4 language mode?
>> 
>> 
>> 
>> -- Ben
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: String Index Overhaul

[Ben Rimmington via swift-evolution]

> On 27 May 2017, at 18:40, Dave Abrahams wrote:
> 
> ## Introduction
> 
> Today `String` shares an `Index` type with its `CharacterView` but not
> with its `UTF8View`, `UTF16View`, or `UnicodeScalarView`.  This
> proposal redefines `String.UTF8View.Index`, `String.UTF16View.Index`,
> and `String.CharacterView.Index` as typealiases for `String.Index`,
> and exposes a public `encodedOffset` property and initializer that can
> be used to serialize and deserialize positions in a `String` or
> `Substring`.

If `encodedOffset` is only needed for serialization of indices, 
could `String.Index` conform to `Codable` from SE-0166 instead?

> ## Proposed solution
> 
> All `String` views will use a single index type (`String.Index`), so
> that positions can be interchanged without awkward explicit
> conversions:
> 
> ```swift
> let html: String = "See http://swift.org\";>swift.org"
> 
> // Search the UTF16, instead of characters, for performance reasons:
> let open = "<".utf16.first!, close = ">".utf16.first!
> let tagStart = s.utf16.index(of: open)
> let tagEnd = s.utf16[tagStart...].index(of: close)

I think `s` should be `html` in the previous two lines.

-- Ben

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

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

[Ben Rimmington via swift-evolution]

Are you using the Swift 4 language mode?



-- Ben

> On 3 Jun 2017, at 23:01, Jens Persson wrote:
> 
> I was notified that my SR-2216 and SR-296 had been "fixed as part of 
> implementing SE-0110".
> 
> But AFAICT SE-0110 can't possibly be fully implemented in dev snapshot 
> 2017-06-02, even though the status of SE-0110 is "Implemented (Swift 4)".
> 
> 
> The title of SE-0110 is
> "Distinguish between single-tuple and multiple-argument function types"
> 
> Keep that in mind while observing the following demonstration of the (Swift 
> 4) behavior of Developer Snapshot 2017-06-02 (a):
> 
> func f(_ a: Int, _ b: Int) { print("\(a), \(b)") }
> func g(_ tuple: (Int, Int)) { print("\(tuple)") }
> f(1, 2) // 1, 2
> g((1, 2)) // (1, 2)
> // Working as expected.
> 
> // But:
> print(type(of: f) == type(of: g)) // true
> // IMHO this is not how to properly
> // "Distinguish between single-tuple and multiple-argument function types"
> 
> // And as if that wasn't enough (pay close attention):
> var (fCopy, gCopy) = (f, g)
> fCopy(1, 2) // 1, 2
> gCopy((1, 2)) // (1, 2)
> swap(&fCopy, &gCopy)
> fCopy(1, 2) // (1, 2)
> gCopy((1, 2)) // 1, 2
> // Crazy!
> 
> I'm trying to put this behavior and the following pieces together:
> 
> 1. The introdoction from SE-0110:
> "Swift's type system should properly distinguish between functions that take 
> one tuple argument, and functions that take multiple arguments."
> 
> 2. The status of SE-0110:
> Implemented (Swift 4)
> 
> 3. The "fixed as part of implementing SE-0110" notification of my bug reports 
> SR-2216: Confusing behavior related to closure types and tuples
> SR-296: Fix inconsistencies related to tuples, arg/param lists, type params, 
> typealiases
> 
> 
> Perhaps SE-0110 is just not fully implemented in dev snapshot 2017-06-02, but 
> it is implemented somewhere, why else should it get the status "implemented"?
> 
> But then I read the following by Vladimir S (one of the SE-0110 authors?): 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036965.html
> 
> It's a very interesting read, and it's nice to see these old inconsistencies 
> are getting some attention (they deserve all the attention they can get), but 
> I'm still confused.
> 
> Is it possible to implement SE-0110 without sorting out the above 
> demonstrated inconsistencies?
> 
> Should status of SE-0110 really be "Implemented"?
> 
> /Jens
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

[Ben Rimmington via swift-evolution]

> On 20 May 2017, at 19:58, Philippe Hausler wrote:
> 
>> On May 20, 2017, at 12:25 AM, David Waite wrote:
>> 
>> I believe behavior depends on whether the NSNumber is the objc type or swift 
>> subtype, and whether you call the NSNumber.intValue or use 
>> Int.init?(exactly: NSNumber).
> 
> That part of the behavior is no longer the case. The bridge only transacts 
> upon one number type (to leverage tagged pointers) and the subclass was 
> removed (since it caused some gnarly inconsistencies)

The subclass `_SwiftTypePreservingNSNumber` still exists:



Maybe the file isn't compiled anymore due to your pull requests:




You mentioned tagged pointers. My understanding is that:

* `OBJC_TAG_NSNumber` doesn't attempt to store a `float` or `double` in the 
60-bit payload;
* `OBJC_TAG_NSDate` is used only if bits 0...3 of the `NSTimeInterval` (aka 
`double`) are zero.



How often is an NSDate (with "sub-millisecond precision") created as a tagged 
pointer?

-- Ben

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

Re: [swift-evolution] [Pitch] Improve String Literals

[Ben Rimmington via swift-evolution]

Re: 


### Support escaping newlines in multi-line strings with a trailing `\`

Markdown can already be "hard-wrapped" in a multi-line string:

Are there any better examples, to show the need for this feature?

### Adopt the C/Objective-C syntax that concatenates single-line strings

Concatenation of adjacent string literals in Swift
(which I think is handled by the *preprocessor* in C)
has a potential hazard [H2] identified by Peter Dillinger:


-- Ben

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

Re: [swift-evolution] [Pitch] Improve String Literals

[Ben Rimmington via swift-evolution]

> On 16 May 2017, at 21:27, Tony Allevato  wrote:
> 
>> On Tue, May 16, 2017 at 1:25 PM David Hart  wrote:
>> The problem I see is that + is an operator of the Standard Library and not 
>> part of the core language. I wouldn’t want + to sometimes to be a runtime 
>> operation and other times a compile-time operation. No, I really think we 
>> need strong language support here.
> 
> Why not? Compile-time concatenation of string literals delimited by `+` 
> sounds like a perfectly reasonable compiler optimization.
> 
> Your argument would also state that the compiler should not do constant 
> folding like turning `5 + 7` into `12`, would it not? What makes that 
> situation different?

When does the compiler do constant folding?

Welcome to Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42). 
Type :help for assistance.
  1> import Foundation
  2> let x: NSNumber = 12
x: __NSCFNumber = Int64(12)
  3> let y: NSNumber = 5 + 7
error: repl.swift:3:21: error: cannot convert value of type 'Int' to 
specified type 'NSNumber'
let y: NSNumber = 5 + 7
  ~~^~~
  NSNumber( )

-- Ben

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

Re: [swift-evolution] [Pitch] Improve String Literals

[Ben Rimmington via swift-evolution]

> On 16 May 2017, at 16:36, Gwendal Roué wrote:
> 
>> Le 16 mai 2017 à 16:58, Tony Allevato  a écrit :
>> 
>> Regarding the C/Objective-C syntax, what would be the advantages over 
>> concatenating the strings with `+`?
> 
> The support for ExpressibleByStringLiteral and 
> ExpressibleByStringInterpolation protocols.

Would it be possible to have compile-time concatenation of *all* string 
literals using the `+` operator?

// Written as:
@available(*, unavailable, message: "Long strings can be bro" +
"ken into two or more pieces.")
// Compiled as:
@available(*, unavailable, message: "Long strings can be broken into 
two or more pieces.")

This could also be used with types such as StaticString, which don't have their 
own `+` operator.

// Written as:
let s: StaticString = "Long strings can be bro" +
  "ken into two or more pieces."
// Compiled as:
let s: StaticString = "Long strings can be broken into two or more 
pieces."

-- Ben

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

Re: [swift-evolution] [Pitch] Build configuration tests

[Ben Rimmington via swift-evolution]

> On 24 Apr 2017, at 21:07, Erica Sadun wrote:
> 
> I'm going to throw this back out into the SE arena to see if there's still 
> interest in these. 
> 
> https://github.com/apple/swift-evolution/pull/369
> 
> It seems to me that many of these are already incorporated into the language 
> as private calls, and would only need minimal coding. Given the extremely 
> limited timeline and the high volume of list traffic, I'm looking for 
> specific concerns (or benefits) you see in this pitch.

Instead of:

```swift
#if interop(objc)
// Code that depends on Objective-C
#endif
```

Would the following be equivalent?

```swift
#if canImport(ObjectiveC)
// Code that depends on Objective-C
#endif
```

Could the `canImport(ObjectiveC)` test also replace the `vendor(Apple)` test?

-- Ben

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

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

[Ben Rimmington via swift-evolution]

> On 20 Apr 2017, at 17:48, Adrian Zubarev wrote:
> 
> Some words about the trailing precision. Joe said that we could use \("") as 
> workaround, but if I recall correctly literals are banned from the 
> interpolation itself, which will result in us doing something like this:
> 
> let end = ""
> 
> let myString = """
>foo\(end)
>"""
> This is a very dirty and tedious solution for that problem.
> 



* Expressions interpolated in strings may now contain string literals.
  For example, `My name is \(attributes["name"]!)` is now a valid expression.
  **(14050788)**

-- Ben

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ben Rimmington via swift-evolution]

> On 6 Apr 2017, at 16:29, Ricardo Parada via swift-evolution 
>  wrote:
> 
> Another thought on the use of single quotes (an possibly the proposed escape 
> character).  Do you think the closing single quote could be made optional 
> since key paths cannot have spaces? Or would that be confusing for beginners?

Key paths can (probably) have spaces:

Welcome to Apple Swift version 3.1 (swiftlang-802.0.48 clang-802.0.48).
  1> Double.nan.isNaN
$R0: Bool = true
  2> Double . nan . isNaN
$R1: Bool = true
  3> Double .nan .isNaN
$R2: Bool = true
  4> Double. nan. isNaN
error: extraneous whitespace after '.' is not permitted
Double. nan. isNaN
  ^~

> For example, these two would be equivalent:
> 
>let isPuppyPredicate = 'Pet.type == .dog && 'Pet.age < 12
>let isPuppyPredicate = 'Pet.type' == .dog && 'Pet.age' < 12
> 
> Or this:
> 
>let isPuppyPredicate = \Pet.type == .dog && \Pet.age < 12
>let isPuppyPredicate = \Pet.type\ == .dog && \Pet.age\ < 12
> 
> You would use the closing character normally when wanting to invoke a method 
> on the key path object.
> 
> Any thoughts?

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ben Rimmington via swift-evolution]

Re: 


> On 6 Apr 2017, at 04:13, Xiaodi Wu wrote:
> 
>> On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada wrote:
>> 
>>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon wrote:
>>> 
>>> It's worth noting that, if you write `\Person.name.valueType`, this syntax 
>>> is ambiguous—it could mean "make a key path for the `valueType` property on 
>>> `name` property of `Person`", or it could mean "make a key path for the 
>>> `name` property of `Person`, then access the key path's `valueType` 
>>> property". We can solve this by always interpreting it as the former and 
>>> requiring parentheses for the latter—that is, 
>>> `(\Person.name).valueType`—but I thought it was worth calling out 
>>> explicitly.
>> 
>> Good point. 
>> 
>>  I'm thinking about the hypothetical code examples from previous emails:
>> 
>>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> That's an interesting point. While `\` alone seems acceptable, I think it's 
> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
> Can we maybe consider instead:
> 
>   let firstFriendsNameKeyPath = \Person.friends[0].name\

'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:

// Create a key path and use it
let firstFriendsNameKeyPath = 'Person.friends[0].name'
luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"

// or equivalently, with type inferred from context
luke[keyPath: '.friends[0].name'] // "Han Solo"

// [SE-0042][SR-3550] Unapplied method references
'String.lowercased()'  // (String) -> String
'String.lowercased(with:)' // (String, Locale?) -> String

Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends of 
the key path (or method reference).

-- Ben

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

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

[Ben Rimmington via swift-evolution]

> On 4 Apr 2017, at 22:43, Itai Ferber wrote:
> 
>> On 4 Apr 2017, at 1:57, Brent Royal-Gordon wrote:
>> 
>> I like the separation between keyed and unkeyed containers (and I think 
>> "unkeyed" is a good name, though not perfect), but I'm not quite happy with 
>> the unkeyed container API. Encoding a value into an unkeyed container 
>> appends it to the container's end; decoding a value from an unkeyed 
>> container removes it from the container's front. These are very important 
>> semantics that the method names in question do not imply at all.
> 
> I think that consistency of phrasing is really important here, and the action 
> words "encode" and "decode" are even more important to connote than the 
> semantics of pushing and popping.
> (Note that there need not be specific directionality to an unkeyed container 
> as long as the ordering of encoded items is eventually maintained on decode.) 
> But on a practical note, names like encodeAtEnd and decodeFromFront (or 
> similar) don't feel like they communicate anything much more useful than the 
> current encode/decode.

If the unkeyed containers are FIFO then I suggest:

* a `QueuedEncodingContainer` protocol with `enqueue(_:)` methods,
* a `QueuedDecodingContainer` protocol with `dequeue(_:)` methods.

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

Re: [swift-evolution] multi-line string literals.

[Ben Rimmington via swift-evolution]

 (Merged 10 days ago)

> On 3 Apr 2017, at 20:32, Charlie Monroe wrote:
> 
>> On Apr 3, 2017, at 9:25 PM, Ben Rimmington wrote:
>> 
>>> On 3 Apr 2017, at 17:55, Tony Allevato wrote:
>>> 
>>> I just checked with -O and without and was surprised to find that `let x = 
>>> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
>>> "abcdefghi" in the generated assembly code. Maybe it's more difficult than 
>>> it is in some other languages because of operator overloads and different 
>>> kinds of text literals (strings, extended grapheme clusters, Unicode 
>>> scalars)?
>> 
>> Is this a regression since Swift 2.0 added the optimization?
> 
> I'd say it's a regression since 3.0 since I remember testing the optimizer 
> even being able to put together this during compile time:
> 
> struct URLString {
>   let urlString: String
> 
>   init(host: String, path: String, query: String) {
>   self.urlString = "http://"; + host + path + "?" + query
>   }
> }
> 
> URLString(host: "apple.com", path: "/mac", query: "target=imac")
> 
> This produced a single string literal - I confirmed this using MachOView on 
> the final binary...
> 
>>  * Concatenation of Swift string literals, including across multiple 
>> lines, is
>>now a guaranteed compile-time optimization, even at `-Onone`. 
>> **(19125926)**
>> 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Ben Rimmington via swift-evolution]

> On 3 Apr 2017, at 17:55, Tony Allevato wrote:
> 
> I just checked with -O and without and was surprised to find that `let x = 
> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
> "abcdefghi" in the generated assembly code. Maybe it's more difficult than it 
> is in some other languages because of operator overloads and different kinds 
> of text literals (strings, extended grapheme clusters, Unicode scalars)?

Is this a regression since Swift 2.0 added the optimization?

* Concatenation of Swift string literals, including across multiple 
lines, is
  now a guaranteed compile-time optimization, even at `-Onone`. 
**(19125926)**



-- Ben

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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Ben Rimmington via swift-evolution]

Re: 

### C String Interop

Will the `init(cString: UnsafePointer)` API be deprecated in Swift 4 
mode?



It was added by SE-0107 to avoid unsafe pointer conversions:



### C Primitive Types

Will the `CChar` typealias be *unsigned* on some platforms?



Could some of those typealiases in CTypes.swift be moved to a C header, so that 
they're always imported as the correct types for each platform?

//===--- CTypes.h --===//
typedef char   CChar;
typedef signed charCSignedChar;
typedef unsigned char  CUnsignedChar;
typedef short  CShort;
typedef unsigned short CUnsignedShort;
typedef intCInt;
typedef unsigned int   CUnsignedInt;
typedef long   CLong;
typedef unsigned long  CUnsignedLong;
typedef long long  CLongLong;
typedef unsigned long long CUnsignedLongLong;
typedef float  CFloat;
typedef double CDouble;

For example, CTypes.swift for 64-bit Windows currently has:
* `CLong = Int32` versus `CUnsignedLong = UInt`,
* `CLongLong = Int`   versus `CUnsignedLongLong = UInt64`.

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

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

[Ben Rimmington via swift-evolution]

> On 23 Mar 2017, at 19:37, Ben Rimmington wrote:
> 
>> On 22 Mar 2017, at 17:41, Itai Ferber wrote:
>> 
>> What’s the use case that you were thinking of? KeyPaths could be useful in 
>> the case where you don’t need to customize your key names, but cannot 
>> represent a custom case like
>> 
>> public struct Post {
>> var authorID: Int
>> var bodyText: String
>> 
>> private enum CodingKeys : String, CodingKey {
>> case authorID = "author_id"
>> case bodyText = "body_text"
>> }
>> }
>> Or am I misunderstanding?
>> 
> 
> For custom names, the `CodingKeys` enum does seem like the best design, 
> unless an attribute can be used.
> 
>   public struct Post : Codable {
>   @codable(name: "author_id") var authorID: Int
>   @codable(name: "body_text") var bodyText: String
>   }
> 
> If each `KeyPath` encapsulates the type information, the `decode` methods 
> won't need a `type` parameter.
> 
>   /// Primitive decoding methods (for single-value and keyed containers).
>   open class DecodingContainer {
>   open func decode(for keyPath: KeyPath)   throws -> Bool
>   open func decode(for keyPath: KeyPath)throws -> Int
>   open func decode(for keyPath: KeyPath)   throws -> UInt
>   open func decode(for keyPath: KeyPath)  throws -> Float
>   open func decode(for keyPath: KeyPath) throws -> 
> Double
>   open func decode(for keyPath: KeyPath) throws -> 
> String
>   open func decode(for keyPath: KeyPath)   throws -> Data
>   }
> 
>   /// Keyed containers inherit the primitive decoding methods.
>   open class KeyedDecodingContainer : DecodingContainer {
>   open func decode(for keyPath: KeyPath Value>) throws -> Value
>   }

On second thought, "property behaviors" 

 could eventually allow the custom name to be stored in a `KeyPath` subclass.

Key paths would also need `LosslessStringConvertible` conformance. The current 
design only has `CustomDebugStringConvertible` conformance.

-- Ben

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

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

[Ben Rimmington via swift-evolution]

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

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

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

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

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

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

-- Ben

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

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

[Ben Rimmington via swift-evolution]

> On 15 Mar 2017, at 22:40, Itai Ferber wrote:
> 
> 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.

Instead of a CodingKeys enum, could the KeyPath proposal 
 be utilized somehow?

-- Ben

___
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

[Ben Rimmington via swift-evolution]

> On 22 Mar 2017, at 03:16, Xiaodi Wu wrote:
> 
>> On Tue, Mar 21, 2017 at 9:38 PM, Matthew Johnson wrote:
>> 
>>> On Mar 21, 2017, at 9:28 PM, Xiaodi Wu wrote:
>>> 
>>> And couldn't this be enforced by a linter feature that warns if a private 
>>> member beginning with _ is accessed outside of scope?
>> 
>> I don’t like to use naming conventions and linters to catch things that 
>> belong in the language proper.  Hasn’t the community agreed that we don’t 
>> want dialects of Swift?
> 
> Very agreed. But is it a "dialect" when it's spoken by the standard library?

It's a shame the standard library can't use `fileprivate` and `private`, but 
the SDK overlays have the following usage:

$ egrep --include *.swift --recursive '\bfileprivate\b' ./stdlib/public/SDK
[47 results]

$ egrep --include *.swift --recursive '\bprivate\b' ./stdlib/public/SDK
[65 results, 8 of which are at file scope]

-- Ben

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

Re: [swift-evolution] Smart KeyPaths

[Ben Rimmington via swift-evolution]

Re: 

> On 21 Mar 2017, at 13:16, Matthew Johnson wrote:
> 
> I think the language is best served if all unbound members are accessible 
> using the same syntax.  IMO this proposal does the right thing by choosing 
> consistency with existing language features.  The current syntax for unbound 
> methods works and hasn't caused any confusions I'm aware of in practice.  
> 
> I don't feel too strongly about what syntax we use as long as it's concise 
> and works for accessing all unbound members.  If people want to make the case 
> for using `#` instead of `.` to do this I won't object but I won't be a vocal 
> advocate either.  However, I think that should be an independent proposal if 
> somebody wants to pursue it rather than a bike shed on this proposal which 
> would only lead to inconsistency between key paths and unbound methods if it 
> succeeds.

A new syntax for key paths and function references could resolve:

* the "compound name syntax for nullary functions" problem;
  


* the source-breaking change of SE-0042 (if reconsidered for Swift 4);
  


-- Ben

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

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

[Ben Rimmington via swift-evolution]

> On 16 Mar 2017, at 21:14, Matthew Johnson wrote:
> 
>> On Mar 16, 2017, at 4:12 PM, Itai Ferber  wrote:
>> 
>> If throwing subscripts made it in the Swift 4 timeframe, then we would 
>> certainly consider it.
> 
> Cool.  Any comment from the core team on whether this is a possibility?  If 
> it is and nobody else wants to write a proposal I would be willing to do it.

"Throwing Properties and Subscripts" proposal by Brent Royal-Gordon (12 months 
ago):



-- Ben

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

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

[Ben Rimmington via swift-evolution]

Sorry, I actually meant that keys would be ordered **alphabetically** (as they 
are with PropertyListSerialization).

I'm storing output from JSONSerialization in a git repository, and when I 
add/remove a single key-value the entire file changes, due to keys being 
reordered (seemingly at random).

-- Ben

> Itai Ferber wrote:
> 
> By stable ordering, you mean dictionaries with keys being output in the order 
> that they were encoded?
> Potentially, but this would require additional work as neither Swift 
> dictionaries nor NSMutableDictionary support this (reasonable seeing as 
> dictionaries are by definition not sorted), and the current implementation 
> uses JSONSerialization as the concrete serializer. Certainly not impossible, 
> though.
> 
>> On 16 Mar 2017, at 8:49, Ben Rimmington wrote:
>> 
>> 
>> 
>> Could the `JSONEncoder.OutputFormatting.prettyPrinted` case include the 
>> **stable ordering** of keys?
>> 
>> -- Ben
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

[Ben Rimmington via swift-evolution]

Could the `JSONEncoder.OutputFormatting.prettyPrinted` case include the 
**stable ordering** of keys?

-- Ben

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

Re: [swift-evolution] Infer types of default function parameters

[Ben Rimmington via swift-evolution]

Previously:





> On 10 Mar 2017, at 21:40, Kilian Koeltzsch wrote:
> 
> Hi all,
> 
> I sent the message below to swift-users@ ~a day ago, but this might be a 
> better place to ask and gather some discussion. It is a rather minor 
> suggestion and I'm just looking for some opinions.
> 
> Declaring a function that has default parameters currently looks like this:
> 
> func foo(bar: String = "baz") {
> print(bar)
> }
> 
> Now I'm wondering if there would be any problems if it were possible to omit 
> the type annotation for default params and let Swift's type inference handle 
> that. 
> 
> func foo(bar = "baz") {
> print(bar)
> }
> 
> It feels to be equivalent to omitting type annotations with variable 
> declarations. Obviously more complex types would still require annotations 
> being specified. Off the top of my head I can't think of any negative 
> ramifications this might bring, be it in simple function/method declarations 
> or protocol extensions and elsewhere. 
> Any further input or examples for situations where this might cause issues 
> would be much appreciated :)
> 
> Cheers,
> Kilian
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

> On 24 Feb 2017, at 02:05, Ben Cohen wrote:
> 
> Regarding the “Number” protocol: it was felt this is likely to cause 
> confusion with NSNumber, given the NS-prefix-dropping versions of other 
> Foundation types indicate a value-typed concrete type equivalent, which this 
> won’t be. The recommendation is to use “Numeric" instead.

Does the `Error` protocol cause confusion with the `NSError` class?

I think `Number` is better than `Numeric`, because it is consistent with 
`SignedNumber`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Ben Rimmington via swift-evolution]

> On 23 Feb 2017, at 14:23, Xiaodi Wu wrote:
> 
> What happens when you need the backticks for the function name itself? We 
> can't nest them.

func `class`() {}

`class`() // Function call.

`class()` // Function reference.

-- Ben

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

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Ben Rimmington via swift-evolution]

> On 22 Feb 2017, at 07:05, Jacob Bandes-Storch wrote:
> 
> Compound name syntax — foo(_:), foo(bar:), foo(bar:baz:) — is used to 
> disambiguate references to functions. (You might've used it inside a 
> #selector expression.) But there's currently no compound name for a function 
> with no arguments.
> 
> func foo() {}  // no compound syntax for this one :(
> func foo(_ bar: Int) {}  // foo(_:)
> func foo(bar: Int) {}  // foo(bar:)
> func foo(bar: String, baz: Double) {}  // foo(bar:baz:)
> 
> Given these four functions, only the first one has no compound name syntax. 
> And the simple reference "let myfn = foo" is ambiguous because it could refer 
> to any of the four. A workaround is to specify a contextual type, e.g. "let 
> myfn = foo as () -> Void".
> 
> I filed SR-3550  for this a while ago, 
> and there was some discussion in JIRA about it. I'd like to continue 
> exploring solutions here and then write up a formal proposal.

Would the following be an option?

 foo()  // Function call expression.
`foo()` // Function reference (using backticks).

-- Ben

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

Re: [swift-evolution] [Discussion] mailing list alternative

[Ben Rimmington via swift-evolution]

> On 26 Jan 2017, at 18:02, Nate Cook wrote:
> 
>> On Jan 25, 2017, at 3:32 PM, Douglas Gregor wrote:
>> 
>> I’ve looked into Discourse a bit, and it does look very promising. One 
>> *specific* way in which a motivated individual could help would be to take a 
>> look at Discourse’s import scripts and try importing swift-evolution’s 
>> mailing archives with them. We absolutely do not want to lose history when 
>> we switch technologies. Do the messages import well? Are threading and 
>> topics maintained in a reasonable manner? Does Discourse provide effective 
>> UI for looking into past discussions on some specific topic we’re interested 
>> in?
> 
> ✋
> 
> I forged the mighty, turgid rivers of rubyenv, hand-tweaked gem dependencies, 
> and sed-cleaned mbox files to try this out—you can see the results of an 
> import (using one or two day old data) at this address:
>   http://discourse.natecook.com/

Discourse doesn't properly import names with an acute accent:




I'm not sure why "=?utf-8?Q?F=C3=A9lix_Cloutier?=" isn't automatically decoded 
by the Mail library:






-- Ben

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

Re: [swift-evolution] Strings in Swift 4

[Ben Rimmington via swift-evolution]

> On 25 Jan 2017, Dave Abrahams wrote:
> 
>> on Tue Jan 24 2017, Ben Rimmington wrote:
>> 
>> Could you include the latest ICU alongside the Swift standard library?
> 
> To what end?

When iOS 10 and macOS 10.12 were released (2016-09-13),
their "libicucore" was based on ICU 57 (2016-03-23),
with support for Unicode 8 (2015-06-17).

They were using a Unicode standard from 15 months ago,
instead of Unicode 9 from 3 months ago (2016-06-21).
This can only be fixed by changing the ICU schedule.

However, the Swift 4 libraries could include ICU 58 now.
They'd have Unicode 9 conformance during implementation,
and also when deployed back to iOS 7 or macOS 10.9.

That's assuming you need ICU 58 for Unicode 9 conformance:


> If Swift always uses the latest ICU it will sometimes behave
> inconsistently with Foundation.  If you want to use the latest ICU
> yourself, you can always put it in your app bundle.

I think Linux apps can bundle ICU for swift-corelibs-foundation.
But a Swift 4 app deployed to iOS 7 or macOS 10.9 will be using 
ICU 51 with Unicode 6.2 support.

-- Ben

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

Re: [swift-evolution] Strings in Swift 4

[Ben Rimmington via swift-evolution]

> In practice, these semantics will usually be tied to the version of the 
> installed ICU library, which programmatically encodes the most complex rules 
> of the Unicode Standard and its de-facto extension, CLDR.

Unicode is released in June. 

CLDR is released in March and September. 

ICU is released in April and October.

Therefore "libicucore" on Apple platforms will always use an older Unicode 
standard.
For example, iOS 10 and macOS Sierra are using ICU 57, which doesn't support 
Unicode 9.

Could you include the latest ICU alongside the Swift standard library?

-- Ben

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

Re: [swift-evolution] Availability checking of libraries (weak linking?)

[Ben Rimmington via swift-evolution]

> On 19 Jan 2017, at 00:24, Swizzlr wrote:
> 
> Say I have an awesome type, and I provide some extensions that makes it work 
> really well with a few other packages.
> 
> I don't want to force those packages on my users, but if they have them, I 
> want to extend them with my awesome type/function/whatever convenience.
> 
> What can be done in code and package manager to weakly link (not literally, I 
> just mean have that behaviour) my awesome type with all these other libraries?
> 
> This is a prelude to a pitch, if there isn't a decent alternative.
> 
> Tom



#if canImport(...) should be available in Swift 4, thanks to Robert Widmann.




-- Ben

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

Re: [swift-evolution] protocol-oriented integers (take 2)

[Ben Rimmington via swift-evolution]

public protocol Arithmetic {
  init?(exactly source: T)
}

public protocol BinaryInteger : Arithmetic {
  init?(exactly source: T)
}

Should the `init?(exactly:)` initializers belong to the same protocol?
Would this allow generic conversions between integer and floating-point types?
For example, a failable `numericCast` function.

-- Ben

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

Re: [swift-evolution] Allow ' in variable/constant names?

[Ben Rimmington via swift-evolution]

> On 11 Jan 2017, at 13:16, Charlie Monroe wrote:
> 
> Instead, I'd personally love better character support in Swift in the future 
> and allow a Character literals using ' - just like in C, except with Unicode 
> support:
> 
> let myChar = 'x' // Character
> let myChar2 = '∃' // Character
> let myChar3 = '\0' // NUL Character
> let myChar4 = 'xyz' // Error from compiler

This feature was removed (just before the first Swift 1.0 beta). Search for 
"Single-quoted literals are no longer recognized" in the CHANGELOG.



I'm looking forward to the "String re-evaluation" part of Swift 4 stage 1. 
Hopefully, the Character type will also be improved.

-- Ben

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

Re: [swift-evolution] Proposal: Improve Import of Scanner APIs into Swift 3

[Ben Rimmington via swift-evolution]

/// Revised API for avoiding usage of AutoreleasingUnsafeMutablePointer 
and better Optional usage.
/// - Experiment: This is a draft API currently under consideration for 
official import into Foundation as a suitable alternative
/// - Note: Since this API is under consideration it may be either 
removed or revised in the near future
extension Scanner {
public func scanInt() -> Int32?
public func scanInteger() -> Int?
public func scanLongLong() -> Int64?
public func scanUnsignedLongLong() -> UInt64?
public func scanFloat() -> Float?
public func scanDouble() -> Double?
public func scanHexInt() -> UInt32?
public func scanHexLongLong() -> UInt64?
public func scanHexFloat() -> Float?
public func scanHexDouble() -> Double?
public func scanString(string searchString: String) -> String?
public func scanCharactersFromSet(_ set: CharacterSet) -> String?
public func scanUpToString(_ string: String) -> String?
public func scanUpToCharactersFromSet(_ set: CharacterSet) -> 
String?
}

Foundation issues should be discussed on the swift-corelibs-dev list.

-- Ben

> On 30 Nov 2016, at 10:10, Oliver Drobnik via swift-evolution 
>  wrote:
> 
> Working on a function for Foundation’s Scanner I stumbled on this LLVM crash: 
> https://bugs.swift.org/browse/SR-3295 
> 
> This got me thinking about a workaround and I would like to prose this:
> 
> When importing Foundation into Swift 3, all 
> 
> AutoreleasingUnsafeMutablePointer?
> 
> should instead be exposed as simple:
> 
> inout T?
> 
> e.g.
> 
> open func scanString(_ string: String, into result: 
> AutoreleasingUnsafeMutablePointer?) -> Bool
> 
> would become
> 
> open func scanString(_ string: String, into result: inout String?) -> Bool
> 
> 
> The call would stay exactly the same for normal use cases where you specify a 
> receiving variable:
> 
> var string: String?
> scanString("=", into: &string)
> 
> because inout parameters require a &
> 
> 
> for the use case where you don’t require a receiving parameter, a second 
> method without result parameter would be generated:
> 
> open func scanString(_ string: String) -> Bool
> 
> This is necessary because you cannot specify nil or an immutable value for an 
> inout parameter. 
> 
> 
> A fixit/migration would change calls to
> 
> scanString(“foo", into result: nil)
> 
> into
> 
> scanString(“foo")
> 
> 
> The normal call with receiving variable would stay the same. But the case 
> without return would become more concise.
> 
> What do you think?
> 
> kind regards
> Oliver Drobnik
___
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

[Ben Rimmington via swift-evolution]

Re: 


### Conventional Identifiers

`conventional-ident-head → [:Emoji:]`
will include the keycap base characters ('#', '*', ASCII digits).



Does the NFC format prevent emoji ZWJ sequences?


### Symbol Identifiers

You could include both blocks of mathematical operators.
* U+2200 ... U+22FF [:Block=Mathematical_Operators:]
* U+2A00 ... U+2AFF [:Block=Supplemental_Mathematical_Operators:]

-- Ben

___
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

[Ben Rimmington via swift-evolution]

> On 21 Oct 2016, at 13:42, Benjamin Spratling wrote:
> 
> Brackets and symbols are definitely operators.  Different brackets are used 
> to represent various quantum mechanical forms and operations.

The brackets are mostly "bracket pieces":

[:Math_Symbol:]
- [:name=/\bANGLE\b/:]
- [:Emoji:]
- [:ID_Continue:]
- [:NFC_Quick_Check=No:]
& [:Script_Extensions=Common:]
& [:Block=Miscellaneous_Technical:]



> Arrows are also useful as operators, including but not restricted to chemical 
> reactions.

Including arrows, there are 740 operators:

[:Math_Symbol:]
- [:name=/\bANGLE\b/:]
- [:name=EMPTY SET:]
- [:name=INFINITY:]
- [:Emoji:]
- [:ID_Continue:]
- [:NFC_Quick_Check=No:]
& [:Script_Extensions=Common:]
& [[:Block=Arrows:]
   [:Block=General_Punctuation:]
   [:Block=Latin_1_Supplement:]
   [:Block=Mathematical_Operators:]
   [:Block=Miscellaneous_Mathematical_Symbols_A:]
   [:Block=Miscellaneous_Symbols_And_Arrows:]
   [:Block=Supplemental_Arrows_A:]
   [:Block=Supplemental_Arrows_B:]
   [:Block=Supplemental_Mathematical_Operators:]]



-- Ben

___
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

[Ben Rimmington via swift-evolution]

> On 20 Oct 2016, at 15:29, Jonathan S. Shapiro wrote:
> 
> Quick poll as a sanity check on a possible alternative for operators:
> 
> If we admitted [:Sm:] and [:So:] and the traditional ASCII operator 
> characters, would that cover the things that people currently feel passionate 
> about? That would almost certainly be compliant with UAX31 once it settles, 
> and I think it covers all of the cases people have raised here.

I'd exclude [:So:], arrows, brackets and "Miscellaneous Mathematical Symbols B".

[:Math_Symbol:]
- [:name=/\bANGLE\b/:]
- [:name=EMPTY SET:]
- [:name=INFINITY:]
- [:Emoji:]
- [:ID_Continue:]
- [:NFC_Quick_Check=No:]
& [:Script_Extensions=Common:]
& [[:Block=Latin_1_Supplement:]
   [:Block=General_Punctuation:]
   [:Block=Mathematical_Operators:]
   [:Block=Miscellaneous_Mathematical_Symbols_A:]
   [:Block=Supplemental_Mathematical_Operators:]]



Is there a property to test for "pictographic" characters?

-- Ben

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

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

[Ben Rimmington via swift-evolution]

> On 11 Oct 2016, at 07:16, Karl wrote:
> 
> You might expect this code to work:
> 
> func aFunction() -> Int?   { return 5 }
> func bFunction() throws -> Int { return 4 }
> 
> let value = aFunction() ?? try bFunction() // ERROR: Operator can throw but 
> expression is not marked with a ‘try'
> print(value)
> 
> Instead, you must put the ‘try’ before the entire expression:
> 
> let value = try aFunction() ?? bFunction()
> 
> This is awkward, since aFunction() doesn’t throw.
> I propose we change the grammar to allow the first example and disallow the 
> second, consistent with the idea that throwing calls are ‘marked’ by using 
> the try keyword.

The `??` function rethrows an error from its rhs operand.

@_transparent
public func ?? (optional: T?, defaultValue: @autoclosure () throws 
-> T)
rethrows -> T {
  switch optional {
  case .some(let value):
return value
  case .none:
return try defaultValue()
  }
}



-- Ben

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

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

[Ben Rimmington via swift-evolution]

> On 4 Oct 2016, at 19:16, Joe Groff wrote:
> 
>> On Oct 4, 2016, at 11:07 AM, Adrian Zubarev 
>>  wrote:
>> 
>> Doesn’t this imply more performance cost? Don’t get me wrong but the value 
>> here is not fixed and computed all over again which might waste resources if 
>> the calculation is complicated. Sure we could build some workarounds here 
>> and there, but the codebase won’t get any prettier after that.
> 
> I doubt it. Formally, integer and string literals are also constructor calls, 
> but they're inlined and constant-folded away in most cases. A struct 
> construction is also likely to be optimized. The code pattern I presented is 
> exactly what the compiler automatically generates when you use the sugar 
> syntax.
> 
> -Joe

It can be surprising when enum cases don't behave like `static let` properties:

Welcome to Apple Swift version 3.0 (swiftlang-800.0.46.2 
clang-800.0.38).
  1> import Foundation
  2> enum Test: NSString {
  3. case test
  4. }
  5> Test.test.rawValue === Test.test.rawValue
$R0: Bool = false

-- Ben

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

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

[Ben Rimmington via swift-evolution]

Yes, but <https://github.com/apple/swift/pull/2379> uses 
`Builtin.unreachable()` because it:

> "Saves a bit of code size in the standard library by eliminating some
> static strings and function calls."

Clang has both `__builtin_unreachable()` and `llvm_unreachable()`:

<http://clang.llvm.org/docs/LanguageExtensions.html#builtin-unreachable>

<http://llvm.org/docs/CodingStandards.html#assert-liberally>

-- Ben

> On 3 Oct 2016, at 20:01, Robert Widmann  wrote:
> 
> fatalError has defaults for its arguments so it can be used as a nullary 
> unreachable function already.
> 
> ~Robert Widmann
> 
>> On Oct 3, 2016, at 2:50 PM, Ben Rimmington via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Instead of using `fatalError(_:file:line:)` in `default` cases, would a 
>> public `unreachable()` function be more efficient?
>> 
>> e.g. <https://github.com/apple/swift/pull/2379 
>> <https://github.com/apple/swift/pull/2379>>
>> 
>> -- Ben
>> 
>>> On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> -1 from me too.
>>> 
>>> Avoiding having to write "default: break" isn't a good justification to 
>>> introduce new syntax. It would make the understanding of case switches 
>>> harder without providing any real benefit for the syntax bloat.
>>> 
>>> João Pinheiro
>>> 
>>> 
>>>> On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution 
>>>> mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> -1 from me as well. This suggestion falls into the same category as those 
>>>> about making `else` optional after `guard`, which is repeatedly rejected. 
>>>> Since code is read more often than written, explicit handling of the 
>>>> default case never hurts and can increase clarity. Not having to write 
>>>> `default: break` offers no help in writing correct code and IMO can't 
>>>> justify new syntax or the changing of a well-known control statement.
>>>> 
>>>> On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution 
>>>> mailto:swift-evolution@swift.org>> wrote:
>>>> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want 
>>>> to be able to ignore cases that “can’t happen” (so say we, writer of bugs) 
>>>> when they’re clearly in the domain of possible values that can be fed to a 
>>>> switch-case.  Exhaustiveness guarantees wellformedness of a program that 
>>>> does happen to go wrong, and makes it much easier to verify the 
>>>> correctness of the flow of control of the containing block because all 
>>>> points from the switch must be covered.  We also don’t have the type-level 
>>>> tools to convince the checker to allow you to remove unreachable cases.  
>>>> If it’s really a problem that you are writing default cases everywhere, 
>>>> just bailout in a fatal error with a nice description.  It never hurts.
>>>> 
>>>> ~Robert Widmann
>>>> 
>>>>> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
>>>>> mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> I know that there is this note in Commonly Rejected Changes 
>>>>> <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>:
>>>>> 
>>>>> Remove support for default: in switch and just use case _:: default is 
>>>>> widely used, case _ is too magical, and default is widely precedented in 
>>>>> many C family languages.
>>>>> I really like to use the switch instead of if case for pattern matching, 
>>>>> just because it’s neat block design. I do not want to remove default from 
>>>>> switches because it’s a must have and powerful feature.
>>>>> 
>>>>> I’d like to know why switches must be exhaustive. 
>>>>> 
>>>>> switch someValue {
>>>>>  
>>>>> case …:
>>>>> // Do something
>>>>>  
>>>>> case …:
>>>>> // Do something else
>>>>> 
>>>>> default:  
>>>>> () // useless nop; do nothing when no pattern matched
>>>>> }
>>>>> 
>>>>> // VS:
>>>>> 
>>>>> if case … {
>>>>>  
>>>>> } else if case … {
>>>>>  
>>>>> } else if case … {
>>>>>  
>>>>> } // No need for `else`
>>>>> Can’t we make default optional, or at least on non-enum values?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Adrian Zubarev
>>>>> Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

[Ben Rimmington via swift-evolution]

Instead of using `fatalError(_:file:line:)` in `default` cases, would a public 
`unreachable()` function be more efficient?

e.g. 

-- Ben

> On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution 
>  wrote:
> 
> -1 from me too.
> 
> Avoiding having to write "default: break" isn't a good justification to 
> introduce new syntax. It would make the understanding of case switches harder 
> without providing any real benefit for the syntax bloat.
> 
> João Pinheiro
> 
> 
>> On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> -1 from me as well. This suggestion falls into the same category as those 
>> about making `else` optional after `guard`, which is repeatedly rejected. 
>> Since code is read more often than written, explicit handling of the default 
>> case never hurts and can increase clarity. Not having to write `default: 
>> break` offers no help in writing correct code and IMO can't justify new 
>> syntax or the changing of a well-known control statement.
>> 
>> On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want to 
>> be able to ignore cases that “can’t happen” (so say we, writer of bugs) when 
>> they’re clearly in the domain of possible values that can be fed to a 
>> switch-case.  Exhaustiveness guarantees wellformedness of a program that 
>> does happen to go wrong, and makes it much easier to verify the correctness 
>> of the flow of control of the containing block because all points from the 
>> switch must be covered.  We also don’t have the type-level tools to convince 
>> the checker to allow you to remove unreachable cases.  If it’s really a 
>> problem that you are writing default cases everywhere, just bailout in a 
>> fatal error with a nice description.  It never hurts.
>> 
>> ~Robert Widmann
>> 
>>> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I know that there is this note in Commonly Rejected Changes 
>>> :
>>> 
>>> Remove support for default: in switch and just use case _:: default is 
>>> widely used, case _ is too magical, and default is widely precedented in 
>>> many C family languages.
>>> I really like to use the switch instead of if case for pattern matching, 
>>> just because it’s neat block design. I do not want to remove default from 
>>> switches because it’s a must have and powerful feature.
>>> 
>>> I’d like to know why switches must be exhaustive. 
>>> 
>>> switch someValue {
>>>  
>>> case …:
>>> // Do something
>>>  
>>> case …:
>>> // Do something else
>>> 
>>> default:  
>>> () // useless nop; do nothing when no pattern matched
>>> }
>>> 
>>> // VS:
>>> 
>>> if case … {
>>>  
>>> } else if case … {
>>>  
>>> } else if case … {
>>>  
>>> } // No need for `else`
>>> Can’t we make default optional, or at least on non-enum values?
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Out of Scope Issues

[Ben Rimmington via swift-evolution]

> On 28 Sep 2016, at 08:23, Haravikk wrote:
> 
> Also, is there a description somewhere of exactly what's in scope for the 
> next stage? The front-page for the swift-evolution github project seems to 
> still be focused on Swift 3.0, is there a permanent description somewhere? I 
> haven't been as active on the list lately so apologies if I've just missed it!



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

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

[Ben Rimmington via swift-evolution]

> On 28 Sep 2016, at 22:27, Erica Sadun wrote:
> 
> Why not rename `CharacterSet` to `UnicodeScalarSe`t, and update the 
> initializers
> to reflect they're being initialized from the unicode scalars in strings and 
> ranges?

I agree, but `UnicodeScalarSet` was rejected during the SE-0069 discussion:



-- Ben

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

Re: [swift-evolution] [Review] SE-0141: Availability by Swift version

[Ben Rimmington via swift-evolution]

Re: 


Is the "Versioned API" design in docs/LibraryEvolution.rst not intended for the 
Swift standard library?





-- Ben

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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Ben Rimmington via swift-evolution]

> On 14 Sep 2016, at 17:08, Andrew Trick via swift-evolution 
>  wrote:
> 
>> On Sep 10, 2016, at 5:53 PM, Andrew Trick  wrote:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md
>> 
>> The review period has been extended until September 14. The 
>> UnsafeRawBufferPointer type name is settled, but we still need to come up 
>> with an answer for the name of the new closure taking functions:
>> 
>> withXyz() should normally reveal the closure argument type as Xyz. That's 
>> why I originally proposed UnsafeBytes as the type name. Now that we've 
>> decided to use the descriptive type instead we have a problem…
> 
> I was totally wrong about this policy. In closure-taking “withXyz" functions, 
> “Xyz" should reveal the role of the closure argument, not its type. We do not 
> need to repeat type information.
> 
> We have strong agreement to leave the proposed `withUnsafeBytes {…}` name as 
> it stands.
> 
> Note that `withRawBytes` was a strong contender, but at this time it's more 
> important to consistently follow the convention for using `Unsafe` in the 
> closure name whenever the closure argument is unsafe (e.g. you can't return 
> it from the closure). We may want to revisit this logic later (in some sense 
> Unsafe is redundant), but when we do that, we also need to reevaluate all of 
> our withUnsafe APIs. Furthermore, we would want to change Foundation Data's 
> API to be consistent. These are bigger debates that can be deferred.

An example without `Unsafe` in the function name:



-- Ben

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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Ben Rimmington via swift-evolution]

> On 11 Sep 2016, at 01:53, Andrew Trick wrote:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md
> 
> The review period has been extended until September 14. The 
> UnsafeRawBufferPointer type name is settled, but we still need to come up 
> with an answer for the name of the new closure taking functions:
> 
> withXyz() should normally reveal the closure argument type as Xyz. That's why 
> I originally proposed UnsafeBytes as the type name. Now that we've decided to 
> use the descriptive type instead we have a problem...

Does the `enumerateBytes` method (of Foundation.Data and DispatchData) also 
need an UnsafeRawBufferPointer version?

-- Ben

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 9 Sep 2016, at 12:09, Tim Vermeulen wrote:
> 
> The new integer protocols (Arithmetic, FixedWidthInteger, etc) aren’t 
> supposed to be in Swift 3.0, right? They show up in the latest snapshot.

"SE-0104: Protocol-oriented integers" was removed from the `swift-3.0-branch` 
in 

A partial implementation is in the `master` branch:

* Merged: 
* Merged: 
* Open:   

-- Ben

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

Re: [swift-evolution] [Meta] Proposal status page

[Ben Rimmington via swift-evolution]

> On 6 Sep 2016, at 07:11, Jacob Bandes-Storch  wrote:
> 
> Is it possible to have a repo named apple.github.io, and still allow 
> individual repos having their own pages (like 
> apple.github.io/swift-evolution)?

The `username.github.io` and `username.github.io/projectname` combination works 
for me.

The `orgname.github.io` and `orgname.github.io/projectname` combination should 
also work (but I haven't tried it).



-- Ben

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

Re: [swift-evolution] [Meta] Proposal status page

[Ben Rimmington via swift-evolution]

> On 21 Jul 2016, at 19:10, Jordan Rose wrote:
> 
>> On Jul 18, 2016, at 16:57, Mark Lacey wrote:
>> 
>>> On Jul 18, 2016, at 4:44 PM, Jacob Bandes-Storch wrote:
>>> 
>>> This is now live:  http://apple.github.io/swift-evolution/
>> 
>> Very very nice!
>> 
>> I wonder if we should do something to avoid the 404 here though: 
>> http://apple.github.io
>> 
>> Perhaps a redirect to https://github.com/apple/swift or maybe directly to 
>> https://github.com/apple/swift/blob/master/README.md?
> 
> The Swift Open Source project isn’t the only project under github.com/apple. 
> Any landing page here would have to come from Apple PR.

You could add a simple 
 file:



https://developer.apple.com/opensource/"; />
404 Not Found

That will redirect to the URL which also appears at the top of the 
 page.

-- Ben

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

Re: [swift-evolution] [Meta] Proposal status page

[Ben Rimmington via swift-evolution]

> On 14 Jul 2016, at 09:30, Jacob Bandes-Storch wrote:
> 
> I got sidetracked today and mocked up a proposal "status page":
> 
> http://jtbandes.github.io/swift-evolution/
> 
> This moves the proposal status info (currently in README.md) into a separate 
> "source of truth":
> 
> https://github.com/jtbandes/swift-evolution/blob/master/proposals.xml
> 
> The status page is then generated from the source of truth using XSLT. 
> Unfortunately, in order to get this working on GitHub Pages, I had to load 
> the files using JavaScript (otherwise the browser blocks the cross-origin 
> requests): 
> https://github.com/jtbandes/swift-evolution/blob/gh-pages/index.html.

This new feature was added to GitHub Pages a few weeks ago:



You might be able to publish from the `master` branch, without using JavaScript:



-- Ben

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

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

[Ben Rimmington via swift-evolution]

> On 3 Sep 2016, at 19:13, Brandon Knope  wrote:
> 
> Thank you! I was looking for this last night and failed. 
> 
> Why do you think {public} isn't included?

I don't know, but trying to reimplement __builtin_os_log_format in the overlay 
seems wrong. It would be better to have a variant of __builtin_os_log_format 
which takes a va_list.

-- Ben

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

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

[Ben Rimmington via swift-evolution]

> On 3 Sep 2016, at 04:24, Brandon Knope wrote:
> 
> I am unsure where to post this…but iOS 10 is introducing a new API for 
> activity tracing and logging.
> 
> The API has been “Swift-ified” a little, but it still is a little awkward to 
> use:
> 
> os_log("Sender: %{public}@", log: ViewController.ui_log, type: .debug, sender)
> 
> (This is taken from: 
> https://developer.apple.com/library/prerelease/content/samplecode/Logging/Introduction/Intro.html#//apple_ref/doc/uid/TP40017510
>  
> )
> 
> Note: the {public} modifier above does not work in swift but does in 
> Objective-C. I have filed a radar for this.

Activity Tracing (2014) and Unified Logging (2016) APIs are complex 
preprocessor macros, which are not imported into Swift.





The os_log_with_type macro in  uses __builtin_os_log_format to encode 
its arguments into a byte array. The overlay for Swift instead uses its 
_os_log_encode C++ function, which only recognizes the {private} modifier.






> A few things:
> • This looks like how the Dispatch APIs use to look: very C-like which was 
> made to be much better in The Great Renaming
> • Cannot use Swift’s string interpolation, resulting in the arguments being 
> passed in at the end
> 
> For reference, this is what it looks like in Objective-C, showing that SOME 
> renaming has occurred: 
> os_log_debug(ui_log, "Sender: %{public}@", sender);
> 
> This might look more Swift-like:
> uiLog.log("Sender: %{public}\(sender)”, type: .debug)
> * Makes “log” a method on an OSLog object 
> • Uses string interpolation

The format string of os_log APIs is required to be constant. The overlay uses a 
StaticString, which isn't ExpressibleByStringInterpolation. SE-0137 also 
deprecated the protocol, so that it can be redesigned.




An instance method of OSLog might be better, except when using the `default` 
object.

OSLog.default.log("message")

Similarly, the Swift.print(_:separator:terminator:to:) function might be better 
as a TextOutputStream method.

-- Ben

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

Re: [swift-evolution] Calling a Specific Implementation

[Ben Rimmington via swift-evolution]

> On 18 Aug 2016, at 16:32, John McCall  wrote:
> 
> Unapplied method references still dispatch down.  It's a pretty simple 
> experiment to run for yourself.

When I tried calling a specific superclass implementation, there was a stack 
overflow due to the infinite recursion.

class Once {
func value() -> Int {
return 1
}
}

class Twice: Once {
override func value() -> Int {
return 2
}
}

class Thrice: Twice {
override func value() -> Int {
return 3

// EXC_BAD_ACCESS:
// return Once.value(self)()
}
}

let once = Once()
once.value()//-> 1
Once.value(once)()  //-> 1

let twice = Twice()
twice.value()   //-> 2
Once.value(twice)() //-> 2
Twice.value(twice)()//-> 2

let thrice = Thrice()
thrice.value()  //-> 3
Once.value(thrice)()//-> 3
Twice.value(thrice)()   //-> 3
Thrice.value(thrice)()  //-> 3

-- Ben

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

Re: [swift-evolution] Calling a Specific Implementation

[Ben Rimmington via swift-evolution]

> On 18 Aug 2016, at 02:57, John McCall wrote:
> 
> Being able to bypass another class's overrides and jump to a specific 
> superclass implementation on an arbitrary method call is badly 
> encapsulation-breaking, and I can't think of any OO language with first-class 
> support for it besides C++.  In every other language I know of, super 
> dispatch is always restricted to the self object and only bypasses the 
> overrides of the current class and its subclasses. Of course there are 
> runtime tricks you can play to get this in, say, ObjC, but I'm not aware of 
> them being frequently used.  I would really to see concrete evidence of this 
> being useful and necessary before considering it any further.

Doesn't this already exist as "unapplied method references" in Swift?



SE-0042 isn't implemented yet, so maybe the curried version should be 
deprecated?

-- Ben

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

Re: [swift-evolution] Allow trailing comma in guard, if-let, et al

[Ben Rimmington via swift-evolution]

> On 18 Aug 2016, at 00:13, Rick Mann wrote:
> 
> Is there any reason Swift can't allow a trailing comma in constructs like 
> this:
> 
> guard
>let a = ...,
>let b = ...,
>let c = ...,
> else
> {
> }
> 
> doing so makes it a bit easier to rearrange lines, and is similar to the 
> trailing comma allowed inside array and dictionary definitions:
> 
> let a = [ 1, 2, 3, ]

A similar proposal was rejected:



-- Ben

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

Re: [swift-evolution] Required Callback

[Ben Rimmington via swift-evolution]

What are the differences between 
 and 

?

application(_:handleEventsForBackgroundURLSession:completionHandler:) 
has an @escaping `completionHandler`, so can @required be enforced?



-- Ben

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 12 Aug 2016, at 21:03, Dave Abrahams wrote:
> 
>> on Fri Aug 12 2016, Ben Rimmington wrote:
>> 
>>> On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
>>> 
>>> Deprecate the ExpressibleByStringInterpolation protocol with a
>>> message indicating that its design is expected to change.  We know
>>> this protocol to be mis-designed
>>> (https://bugs.swift.org/browse/SR-1260) and limited
>>> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>>> for Swift 3.  If we knew what the new design should look like, we
>>> might be able to calculate that the current API is supportable in a
>>> forward-compatible way (as we do for Comparable).  Unfortunately, we
>>> do not.
>> 
>> Can the deprecation of ExpressibleByStringInterpolation be reverted next 
>> year,
>> if a backwards-compatible design is proposed for Swift 4.0?
> 
> Yes, that's the plan, even if a backwards-compatible design isn't
> proposed.  The reason to deprecate it now is that we're not sure a
> backwards-compatible design will be possible.

The only downside is when manually converting to current Swift syntax:

1. ⚠️ 'StringInterpolationConvertible' is deprecated: 
renamed to 'ExpressibleByStringInterpolation'

2. ☑️ Fix-it: Use 'ExpressibleByStringInterpolation' instead

3. ⚠️ 'ExpressibleByStringInterpolation' is deprecated: 
it will be replaced or redesigned in Swift 4.0.  
Instead of conforming to 'ExpressibleByStringInterpolation', 
consider adding an 'init(_:String)'

-- Ben

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
> 
> Deprecate the ExpressibleByStringInterpolation protocol with a
> message indicating that its design is expected to change.  We know
> this protocol to be mis-designed
> (https://bugs.swift.org/browse/SR-1260) and limited
> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
> for Swift 3.  If we knew what the new design should look like, we
> might be able to calculate that the current API is supportable in a
> forward-compatible way (as we do for Comparable).  Unfortunately, we
> do not.

Can the deprecation of ExpressibleByStringInterpolation be reverted next year,
if a backwards-compatible design is proposed for Swift 4.0?

-- Ben

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 11 Aug 2016, at 00:24, Brent Royal-Gordon wrote:
> 
>> On Aug 9, 2016, at 12:09 PM, Dave Abrahams wrote:
>> 
>> Deprecate the Indexable protocols with a message indicating that they
>> will be gone in Swift 4.
> 
> Should IndexableBase get the same treatment?

Yes, see  from the SE-0137 proposal.



-- Ben

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

[swift-evolution] Use lowerCamelCase for @warn_unqualified_access attribute?

[Ben Rimmington via swift-evolution]

I noticed that the @warn_unqualified_access attribute in LibraryEvolution 
hasn't been updated to lowerCamelCase.



It's currently used by the `min` and `max` methods of Sequence, and the `print` 
methods in AppKit.





It doesn't have the UserInaccessible option, so can @warn_unqualified_access 
also be used in client code?



-- Ben

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 10 Aug 2016, at 22:44, Erica Sadun wrote:
> 
>> On Aug 9, 2016, at 1:09 PM, Dave Abrahams wrote:
>> 
>> Hi Everybody,
>> 
>> With another round of apologies for taking late action, we propose to
>> make some deprecations, moves, and renames.  The background for these
>> moves is as follows:
>> 
>> We've always known that when Swift reached ABI stability (now slated for
>> Swift 4), we would be committed to supporting many of the standard
>> library's design decisions for years to come.  What we only realized
>> very recently is that, although Swift 3.0 is *not* shipping with a
>> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
>> code creates similar implications when it comes to certain protocols,
>> today.  Especially where these protocols show up in refinement
>> hierarchies, we can't keep Swift 3 code working in the future without
>> carrying them forward into future libraries.
>> 
>> The proposed changes are as follows:
>> 
>> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>> This component is really only useful for playgrounds, and doesn't
>> belong in the standard library.
> 
> This seems like an obvious win. I *strongly* support this. (Didn't we discuss 
> this
> several weeks ago?)

Yes, we did:



But that part of the proposal has been withdrawn:



> Since you've opened the doors to last minute discussions, I also feel quite 
> strongly
> that image/color/file literals are misplaced and do not belong as part of the 
> standard library. The image one is the best example of the misfit. Images 
> will probably 
> never be a core component of stdlib but they don't fit in PlaygroundSupport 
> either as they 
> are essentially EditorSupport-ive. They have value across multiple platforms 
> (currently
> OS X and the UIKit family, but primarily act in an Xcode-support role) but 
> could be extended
> to other editors and other platforms. (And yes, I have list of other items 
> but they fall well
> outside the scope of the current Swift Ev discussion so I'm sitting on them.)
> 
>> * Deprecate the Indexable protocols with a message indicating that they
>> will be gone in Swift 4.  These protocols are implementation details
>> of the standard library designed to work around language limitations
>> that we expect to be gone in Swift 4.  There's no reason for anyone to
>> ever touch these; users should always use a corresponding Collection
>> protocol (e.g. instead of MutableIndexable, use MutableCollection).
> 
> It's time to for indices to evolve. 
> 
>> * Deprecate the ExpressibleByStringInterpolation protocol with a
>> message indicating that its design is expected to change.  We know
>> this protocol to be mis-designed
>> (https://bugs.swift.org/browse/SR-1260) and limited
>> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>> for Swift 3.  If we knew what the new design should look like, we
>> might be able to calculate that the current API is supportable in a
>> forward-compatible way (as we do for Comparable).  Unfortunately, we
>> do not.
> 
> I'm glad you're thinking forward about this.
> 
>> * Rename Streamable to TextOutputStreamable and add a deprecated
>> Streamable typealias for it.  Now that OutputStream been renamed to
>> TextOutputStream, we should also move Streamable out of the way.
> 
> Fine. Now if only I could figure out how to get this working. Been
> banging my head against the new streaming stuff. Also it shouldn't be
> this hard to print(toStream: CustomCustomCustomBlah.stderr)

See the LocalFileOutputByteStream class and the `<<<` operator in:



>> Deprecation is being proposed instead of underscoring or renaming
>> because it allows existing code to keep working (with warnings).  At
>> this late stage, it would be bad to actually break anything.
> 
> Sensible.
> 
> -- E

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 10 Aug 2016, at 17:24, Dave Abrahams wrote:
> 
>> on Wed Aug 10 2016, Ben Rimmington wrote:
>> 
>> In apple/swift#4131, these lines have overrun the 80 column limit:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> TextFormatting.rst also needs `Streamable` => `TextOutputStreamable`:
>> 
>> 
> 
> Pull requests gratefully accepted for all of these corrections




-- Ben

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 10 Aug 2016, at 00:36, Dave Abrahams wrote:
> 
>> on Tue Aug 09 2016, Ben Rimmington wrote:
>> 
>>> On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
>>> 
>>> Hi Everybody,
>>> 
>>> With another round of apologies for taking late action, we propose to
>>> make some deprecations, moves, and renames.  The background for these
>>> moves is as follows:
>>> 
>>> We've always known that when Swift reached ABI stability (now slated for
>>> Swift 4), we would be committed to supporting many of the standard
>>> library's design decisions for years to come.  What we only realized
>>> very recently is that, although Swift 3.0 is *not* shipping with a
>>> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
>>> code creates similar implications when it comes to certain protocols,
>>> today.  Especially where these protocols show up in refinement
>>> hierarchies, we can't keep Swift 3 code working in the future without
>>> carrying them forward into future libraries.
>>> 
>>> The proposed changes are as follows:
>>> 
>>> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>>> This component is really only useful for playgrounds, and doesn't
>>> belong in the standard library.
>> 
>> I didn't think it was possible to `import PlaygroundSupport` unless the 
>> current file is within a playground. If so, how can corelibs-foundation 
>> or third-party modules add `CustomPlaygroundQuickLookable`
>> conformance?
> 
> Ahhh... yeah, I didn't realize that, and we don't have time to change
> that restriction for Swift 3.  It's not a problem for
> corelibs-foundation but it would be for 3rd-party libraries.  
> 
> OK, Dmitri and I just figured out how we can change the home of these
> types for Swift 4 without breaking Swift 3 code (mirrors to the rescue!)
> So I'm going to withdraw this part of the proposal.

Will the following need to be reverted?









>>> * Deprecate the Indexable protocols with a message indicating that they
>>> will be gone in Swift 4.  These protocols are implementation details
>>> of the standard library designed to work around language limitations
>>> that we expect to be gone in Swift 4.  There's no reason for anyone to
>>> ever touch these; users should always use a corresponding Collection
>>> protocol (e.g. instead of MutableIndexable, use MutableCollection).
>>> 
>>> * Deprecate the ExpressibleByStringInterpolation protocol with a
>>> message indicating that its design is expected to change.  We know
>>> this protocol to be mis-designed
>>> (https://bugs.swift.org/browse/SR-1260) and limited
>>> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>>> for Swift 3.  If we knew what the new design should look like, we
>>> might be able to calculate that the current API is supportable in a
>>> forward-compatible way (as we do for Comparable).  Unfortunately, we
>>> do not.
>>> 
>>> * Rename Streamable to TextOutputStreamable and add a deprecated
>>> Streamable typealias for it.  Now that OutputStream been renamed to
>>> TextOutputStream, we should also move Streamable out of the way.

In apple/swift#4131, these lines have overrun the 80 column limit:







TextFormatting.rst also needs `Streamable` => `TextOutputStreamable`:



>>> Deprecation is being proposed instead of underscoring or renaming
>>> because it allows existing code to keep working (with warnings).  At
>>> this late stage, it would be bad to actually break anything.
>> 
>> If the SE-0104 (protocol-oriented integers) proposal has been deferred, 
>> should any protocols (e.g. SignedNumber) be deprecated?

Will the SE-0104 proposal be accepted for Swift 4.0?

-- Ben

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
> 
> Hi Everybody,
> 
> With another round of apologies for taking late action, we propose to
> make some deprecations, moves, and renames.  The background for these
> moves is as follows:
> 
> We've always known that when Swift reached ABI stability (now slated for
> Swift 4), we would be committed to supporting many of the standard
> library's design decisions for years to come.  What we only realized
> very recently is that, although Swift 3.0 is *not* shipping with a
> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> code creates similar implications when it comes to certain protocols,
> today.  Especially where these protocols show up in refinement
> hierarchies, we can't keep Swift 3 code working in the future without
> carrying them forward into future libraries.
> 
> The proposed changes are as follows:
> 
> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>  This component is really only useful for playgrounds, and doesn't
>  belong in the standard library.

I didn't think it was possible to `import PlaygroundSupport` unless the 
current file is within a playground. If so, how can corelibs-foundation 
or third-party modules add `CustomPlaygroundQuickLookable` conformance?

> * Deprecate the Indexable protocols with a message indicating that they
>  will be gone in Swift 4.  These protocols are implementation details
>  of the standard library designed to work around language limitations
>  that we expect to be gone in Swift 4.  There's no reason for anyone to
>  ever touch these; users should always use a corresponding Collection
>  protocol (e.g. instead of MutableIndexable, use MutableCollection).
> 
> * Deprecate the ExpressibleByStringInterpolation protocol with a
>  message indicating that its design is expected to change.  We know
>  this protocol to be mis-designed
>  (https://bugs.swift.org/browse/SR-1260) and limited
>  (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>  for Swift 3.  If we knew what the new design should look like, we
>  might be able to calculate that the current API is supportable in a
>  forward-compatible way (as we do for Comparable).  Unfortunately, we
>  do not.
> 
> * Rename Streamable to TextOutputStreamable and add a deprecated
>  Streamable typealias for it.  Now that OutputStream been renamed to
>  TextOutputStream, we should also move Streamable out of the way.
> 
> Deprecation is being proposed instead of underscoring or renaming
> because it allows existing code to keep working (with warnings).  At
> this late stage, it would be bad to actually break anything.

If the SE-0104 (protocol-oriented integers) proposal has been deferred, 
should any protocols (e.g. SignedNumber) be deprecated?

-- Ben

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

Re: [swift-evolution] [Pre-proposal/Discussion] Padding and Smaller Integer Types?

[Ben Rimmington via swift-evolution]

> On 3 Aug 2016, at 13:15, Haravikk wrote:
> 
> So we have a pretty good set of integer types right now, but one issue I come 
> into is when they don't quite fit within the padding of a type. It's not 
> something I've ever really thought about before, since most of my background 
> is in OOP with reference types (Java for example) and these don't really 
> encourage you to think about it, but with value types I find myself doing so 
> quite a lot.
> 
> For example, an Int32? has space for a four-byte integer value, plus one 
> extra bit to indicate whether it is a .None or a .Some, this means that it's 
> padded to 5-bytes. If I create a struct containing an optional Int32, I have 
> seven bits of free space before the type grows in size again (more if I 
> target the type's stride width), so I could add up to seven Bool values if I 
> wanted in this case.
> But what if I want to add another small integer? If I add a UInt8 this will 
> cause the type's size to grow (as it'll still have one-bit of extra 
> overhead), but I may not require the full range from the UInt8.
> 
> The simple solution to this might be introduce an Octet type (Int4/UInt4) but 
> that may actually be smaller than I need; what if what I would really like is 
> a UInt7 type?
> 
> 
> Now I'm not very familiar with how other languages solve problems like this; 
> as I say I've mostly worked with reference based OOP languages in the past, 
> and only worked fleetingly with C (I can modify code, but haven't written 
> anything new in it in a very long time), so I guess I'm mostly just looking 
> to find those with more knowledge than me on the subject to see if there are 
> some good solutions to this? Swift's rich support for optionals, and enums in 
> general, make small overheads like this more common, so a neat way to work 
> with them would be nice.
> 
> In my mind the most perfect option would be some kind of integer type for 
> which I can specify a minimum range for what I need, but which I can have 
> scaled in size to fill, but avoid growing, my type's size or stride. For 
> example, if my type is intended for storage in arrays exclusively, then I 
> might like to use up all of the free space in my type's stride width, only 
> growing if it is necessary to achieve the minimum range of values I require. 
> So I might require a minimum range of 0-127 (7 bits unsigned) but end up with 
> a wider type that I can make use of generically by querying the min/max 
> values, i.e- if the remaining space is 7-bits then my integer will fill that 
> perfectly, if the remaining space is 13-bits I will end up with a 13-bit 
> integer, if remaining space is 3-bits the type might grow by 16-bits, giving 
> me a 19-bit integer.
> Is such a thing possible? If so, how is it achieved in other languages?
> 
> 
> Sorry about the lack of knowledge in my part on this subject; like I say it's 
> nothing I've really thought about before, but now that I'm working with a 
> value type that I want to pack as efficiently as possible into an array 
> (while remaining useful) it's something that is suddenly of interest to me =D
> 
> All ideas and thoughts welcome!

UnicodeScalar previously stored its _value as Builtin.Int21 (instead of the 
current UInt32).



There are some out-of-date examples, where enums with UnicodeScalar payloads 
used the spare bits (i32 \ i21) for the tag.




Maybe these strategies can't be used for libraries with binary compatibility?



-- Ben

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Ben Rimmington via swift-evolution]

> On 1 Aug 2016, at 23:03, Brent Royal-Gordon wrote:
> 
> I would love to have a great web archive for swift-evolution—something with a 
> really solid search function, good threading, and most of the other niceties 
> of forums. It'd even be nice to have an upvote feature. But these are all 
> things that you could do without taking swift-evolution off of email.

Mailman 3 with the HyperKitty archiver has those features. For example:



Swift-evolution is currently using Mailman 2.1.12 with Pipermail.

See also:

*  (March 2015: Mailman 3 review)
*  (April 2014: HyperKitty preview)

-- Ben

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

Re: [swift-evolution] [META] Gmane and Swift Evolution

[Ben Rimmington via swift-evolution]

> On 2 Aug 2016, at 16:16, Erica Sadun via swift-evolution 
>  wrote:
> 
> Anyone willing to adopt a proposal or a group and get them updated, please 
> reply in-thread and submit a PR with changes.

[SE-0076 ... SE-0090] 

-- Ben

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

Re: [swift-evolution] [META] Gmane and Swift Evolution

[Ben Rimmington via swift-evolution]

> On 1 Aug 2016, at 00:00, Erica Sadun via swift-evolution 
>  wrote:
> 
>>> On Jul 31, 2016, at 15:42, Chris Lattner via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 
 On Jul 31, 2016, at 3:40 PM, Erica Sadun via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Gmane.org  is shutting down. 
 http://ostatic.com/blog/mint-18-xfce-imminent-gmane-org-shutting-down 
  
 writes:
 
> "Long time mailing list archive site Gmane.org  is 
> shutting down. Gmane has been the home for technical mailing list 
> references since 2002. But it's no longer fun for founder and only 
> maintainer Lars Ingebrigtsen. He's been sued in India and threatened with 
> legal action in at least France, among other annoyances. The straw that 
> broke Ingebrigtsen's back was a sustained denial of service 
>  attack 
> throughout the month of July. He's been wondering a lot lately if it's 
> all worth it. So, he's decided 
> 
>  to move the mail and news servers to new hosting. However, Ingebrigtsen 
> is indeed discontinuing the web-based archive. He said he's just "fed 
> up." He's willing to send a disk with the web server archives to anyone 
> who wants to take it over. But with the Gmane.org  web 
> presence gone, it feels like the end of an era. There is much wailing and 
> gnashing of teeth throughout the community with some even trying to get a 
> petition started."
 
 Because of this shutdown, numerous documents in the Swift Evolution github 
 archive no longer point to valid web links. I have pasted a list of gmane 
 links at the end of this message. As gmane's "robots.txt" disallowed 
 crawling, Google has not preserved the titles or text of the links, which 
 makes finding some of these a little tricky.
 
 Here are the remaining links that are not yet converted. Please consider 
 adopting a proposal, tracking down its links, and mailing this thread with 
 the proposal number, gmane links and pipermail equivalents. Pipermail is 
 located at https://lists.swift.org/pipermail/swift-evolution/ 
 . Some of these may 
 refer to  build dev discussions instead of evolution ones. If you can, 
 please track down to the exact message for rationale, and the thread for 
 discussion and review links.
>>> 
>>> Completely agreed.  All of these should point to https://lists.swift.org 
>>>  (and always should have, exactly for reasons 
>>> like this).  I’d appreciate any PRs to help clean up the evolution repo to 
>>> point to https://lists.swift.org  instead.
>>> 
>>> Thanks!
>>> 
>>> -Chris
> 
>> On Jul 31, 2016, at 4:51 PM, Saagar Jha > > wrote:
>> 
>> I’d be happy to help. I see 94 instances of “gmane", do we want to split it 
>> up (since I see Erica is on it already)?
>> 
>> Saagar Jha
> 
> If you start from the end (most recent proposals) and work backwards, it will 
> be a lot easier for me. Thanks! -- E

I'll update the middle third (SE-0046 ... SE-0090).

-- Ben

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

Re: [swift-evolution] End of source-breaking changes for Swift 3

[Ben Rimmington via swift-evolution]

> On 27 Jul 2016, at 21:52, Jacob Bandes-Storch wrote:
> 
> SE-0089 - Renaming String.init(_: T) 
> 
> 
> Has anyone worked on this? I have some time in the next couple of days and 
> might be able to come up with an implementation in time.



-- Ben

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

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

[Ben Rimmington via swift-evolution]

> On 27 Jul 2016, at 15:08, Xiaodi Wu  wrote:
> 
> Ben, while I'm broadly sympathetic to making CChar work more widely, if I 
> recall correctly this was a rather complex discussion topic you're raising 
> again.

Yes, I linked to the previous threads:






> Besides the unprecedented name (Unsigned is never spelled out at the moment),

No, CSignedChar and CUnsignedChar already exist:




The equivalent Int8 and UInt8 could be used instead.

> I wonder if all the other salient issues involved are best left for a wider 
> discussion than is possible here, especially since the pitch and proposal 
> have been limited to two properties.

Yes, the core team will probably merge 
 without ammendment.

But the fundamental issue is that UTF-8 characters can be treated as signed or 
unsigned:




The utf8CString() methods -- overloaded by return type -- could be useful when 
writing cross-platform code.

I also suggested the other changes for two reasons:

1. Foundation.NSString has many deprecated `cString` APIs, because it wasn't 
clear whether they used the UTF-8 or Mac OS Roman encoding?

2. If the CChar typealias will be defined as UInt8 on some platforms, the 
initializers will conflict:

extension String {
  init(cString: UnsafePointer) // Added by SE-0006.
  init(cString: UnsafePointer) // Added by SE-0107.
}

-- Ben

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

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

[Ben Rimmington via swift-evolution]

> On 25 Jul 2016, at 15:27, Ben Rimmington wrote:
> 
> 
> 
> My suggestion for SE-0134 is to use the `utf8CString` name, overloading for 
> CSignedChar and CUnsignedChar:
> 
>   
> 
> 
>   extension String {
>   - init(cString: UnsafePointer)
>   - init(cString: UnsafePointer)
>   - init?(validatingUTF8 cString: UnsafePointer)
> 
>   + init(utf8CString: UnsafePointer)
>   + init(utf8CString: UnsafePointer)
>   + init?(validatingUTF8CString: UnsafePointer)
>   + init?(validatingUTF8CString: UnsafePointer)
>   }
> 
> The properties would change to methods, overloaded by return type:
> 
>   
> 
> 
>   extension String {
>   - var nulTerminatedUTF8CString: ContiguousArray
>   - var nulTerminatedUTF8: ContiguousArray
> 
>   + func utf8CString() -> ContiguousArray
>   + func utf8CString() -> ContiguousArray
>   }
> 
> ## NOTES ##
> 
> UTF8.CodeUnit is defined as UInt8, and CChar is currently defined as Int8:
> 
>   
> 
> 
>   /// The C 'char' type.
>   ///
>   /// This will be the same as either `CSignedChar` (in the common
>   /// case) or `CUnsignedChar`, depending on the platform.
>   public typealias CChar = Int8
> 
>   /// The C 'signed char' type.
>   public typealias CSignedChar = Int8
> 
>   /// The C 'unsigned char' type.
>   public typealias CUnsignedChar = UInt8
> 
> There's an abandoned proposal to update CChar:
> 
>   
> 
> 
>   
> 
> String.init(cString: UnsafePointer) and nulTerminatedUTF8CString were 
> added by SE-0107:
> 
>   
> 
> 
>   
> 
> 
> Foundation.NSString uses the `utf8String` name instead:
> 
>   
> 
>   
> 



There's another method for SE-0134 which could be renamed or removed:




extension String {
- func withCString(
-   _ body: @noescape (UnsafePointer) throws -> Result
- ) rethrows -> Result

+ func withUTF8CString(
+   _ body: @noescape (UnsafePointer) throws -> Result
+ ) rethrows -> Result

+ func withUTF8CString(
+   _ body: @noescape (UnsafePointer) throws -> Result
+ ) rethrows -> Result
}

The overloads (CSignedChar and CUnsignedChar) are needed if CChar will become 
UInt8 on some platforms.

-- Ben

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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Ben Rimmington via swift-evolution]

> On 26 Jul 2016, at 16:15, Dave Abrahams wrote:
> 
>>> b. they are given a recognizable domain-specific notation such as:
>>> 
>>>  x.removeSubrange($+n..<)
>>>  x.removeSubrange(..<$-n)
>> 
>> Does $ represent the start, the end, or either one depending on which
>> side of the range we're on? Because if it's the third option, I think
>> these two operations are actually inverted: the first is removing
>> everything *except* the `prefix(n)`, and the second is removing
>> everything except the `suffix(n)`.
> 
> Wow, that was impressive!  With one stroke, you have just convinced me
> that we can't do this.  The fact that I got it wrong, along with other
> excellent feedback in this thread, kills my interest in using $ in this
> way.

This would also conflict with one of the following:

1. Allowing `$` for the Dollar library.



2. Reserving `$` for the debugger.



(The latter "test and merge" is failing for some reason).

-- Ben

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

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

[Ben Rimmington via swift-evolution]

My suggestion for SE-0134 is to use the `utf8CString` name, overloading for 
CSignedChar and CUnsignedChar:




extension String {
- init(cString: UnsafePointer)
- init(cString: UnsafePointer)
- init?(validatingUTF8 cString: UnsafePointer)

+ init(utf8CString: UnsafePointer)
+ init(utf8CString: UnsafePointer)
+ init?(validatingUTF8CString: UnsafePointer)
+ init?(validatingUTF8CString: UnsafePointer)
}

The properties would change to methods, overloaded by return type:




extension String {
- var nulTerminatedUTF8CString: ContiguousArray
- var nulTerminatedUTF8: ContiguousArray

+ func utf8CString() -> ContiguousArray
+ func utf8CString() -> ContiguousArray
}

## NOTES ##

UTF8.CodeUnit is defined as UInt8, and CChar is currently defined as Int8:




/// The C 'char' type.
///
/// This will be the same as either `CSignedChar` (in the common
/// case) or `CUnsignedChar`, depending on the platform.
public typealias CChar = Int8

/// The C 'signed char' type.
public typealias CSignedChar = Int8

/// The C 'unsigned char' type.
public typealias CUnsignedChar = UInt8

There's an abandoned proposal to update CChar:






String.init(cString: UnsafePointer) and nulTerminatedUTF8CString were 
added by SE-0107:







Foundation.NSString uses the `utf8String` name instead:






-- Ben

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

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Ben Rimmington via swift-evolution]

> On 22 Jul 2016, at 18:43, Dave Abrahams wrote:
> 
>> on Fri Jul 22 2016, Haravikk  wrote:
>> 
>> In my own hacked implementation I'm using Order.before, Order.same,
>> and Order.after. It's not much of a change, but it seems to clarify
>> what the enum is, at least in my opinion.
> 
> I always thought the name “Order” would be perfect if it weren't so
> short and likely to conflict with type names that user code will want.
> We do have qualification to fall back on, so this is a judgement call.

enum TotalOrder {
  case ascending
  case identical
  case descending
}

-- Ben

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

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Ben Rimmington via swift-evolution]

> On 22 Jul 2016, at 20:43, Jacob Bandes-Storch  wrote:
> 
>> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington  
>> wrote:
>> 
>>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>> 
>>> In the swift-lang Slack channel, a few of us were discussing 
>>> joined(separator:) and realized that flatten() does almost exactly the same 
>>> thing.
>>> 
>>> Is there interest in renaming flatten() to joined()?  Since joined takes a 
>>> separator that's any Sequence, we can't have a default value for the 
>>> separator parameter, but we can have a variant of joined() with no 
>>> arguments.
>> 
>> I'd like default separators for the joined() methods.
>> 
>> 
>> 
>> But renaming flatten() to joined() seems complicated.
>> 
>> 
>> 
> 
> What makes it seem complicated? At the very least, one could just rename the 
> flatten() function. There might also be an opportunity to combine the two 
> files and delete some code from stdlib.

There's only one joined() method (for a sequence of sequences):

extension Sequence {
  func joined(separator: Separator) -> 
JoinedSequence
}

There are many flatten() methods (`where` clauses omitted for brevity):

extension Sequence {
  func flatten() -> FlattenSequence
}

extension LazySequenceProtocol {
  func flatten() -> LazySequence>
}

extension LazyCollectionProtocol {
  func flatten() -> LazyCollection>
}

extension Collection {
  func flatten() -> FlattenCollection
}

extension BidirectionalCollection {
  func flatten() -> FlattenBidirectionalCollection
}

So it's not a simple one-to-one rename.

When there's no `separator` argument, will FlattenIterator perform better than 
JoinedIterator?

>> And what would happen to the flatMap() methods? Is flatten() a term of art?
>> 
>> 
> 
> I'd say flatMap is more a "term of art" than flatten. "flatten" just 
> describes literally what is being done. Frankly I'm surprised it was never 
> named flattened(). Anyway, flatMap should stay.

## Future directions

Will the flatMap(_:) methods also have flatMap(separator:_:) variants?

-- Ben

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