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

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

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

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

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

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

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

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

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

> 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

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

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

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

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:

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

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

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

> 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

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

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

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

DynamicCallable.md DynamicMemberLookup.md JavaScriptCore.JSValue If the JSValue class

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

> 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

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

> 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

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

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

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

> 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

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

> 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

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

Re: Chris Lattner recently commented in that the prototype could use support. In one of the CppCon videos, Gor Nishanov said that C++ coroutines

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

> 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

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

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

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

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

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

> 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

Re: [swift-evolution] Integers and their protocols

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

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

The new `JSONSerialization.WritingOptions.sortedKeys` option was mentioned at WWDC. "What's New in Cocoa" [33:03 ... 33:33] When the

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

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

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

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

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

> 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

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

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

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

> 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

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

Re: ### Support escaping newlines in multi-line strings with a trailing `\` Markdown can already be "hard-wrapped" in a multi-line string:

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

> 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

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

> 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

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

> 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

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

> 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 = "" >

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

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

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

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

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

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

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

(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

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

> 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

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

Re: ### C String Interop Will the `init(cString: UnsafePointer)` API be deprecated in Swift 4 mode? It was added by

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

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

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

> 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

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

> 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

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

> 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

Re: [swift-evolution] Smart KeyPaths

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

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

> 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

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

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

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

Could the `JSONEncoder.OutputFormatting.prettyPrinted` case include the **stable ordering** of keys? -- Ben ___ swift-evolution mailing list swift-evolution@swift.org

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

Previously: > On 10 Mar 2017, at 21:40, Kilian Koeltzsch

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

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

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

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

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

> 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

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

> 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

Re: [swift-evolution] Strings in Swift 4

> 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

Re: [swift-evolution] Strings in Swift 4

> 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

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

> 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

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

public protocol Arithmetic { init?(exactly source: T) } public protocol BinaryInteger : Arithmetic { init?(exactly source: T) } Should the `init?(exactly:)` initializers belong

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

> 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

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

/// Revised API for avoiding usage of AutoreleasingUnsafeMutablePointer and better Optional usage. /// - Experiment: This is a draft API

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

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

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

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

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

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

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

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

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

> 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

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

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

Re: [swift-evolution] Out of Scope Issues

> 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

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

> 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

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

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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> 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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> 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

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

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

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

> 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": > >

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

> 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

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

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

Re: [swift-evolution] Calling a Specific Implementation

> 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

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

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

Re: [swift-evolution] Required Callback

What are the differences between and ? application(_:handleEventsForBackgroundURLSession:completionHandler:) has an @escaping `completionHandler`, so can

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

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

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

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

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

> 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

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

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.

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

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

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

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

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

> 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

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

> 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

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

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

Re: [swift-evolution] [META] Gmane and 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]

Re: [swift-evolution] [META] Gmane and 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 >>> > wrote: >>> On Jul 31, 2016, at 3:40 PM, Erica Sadun

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

> 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

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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

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

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

> On 14 Jul 2016, at 05:47, Chris Lattner via swift-evolution > wrote: > > Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md > >

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On 13 Jul 2016, at 20:04, Pierre Habouzit via swift-evolution > wrote: > > I strongly disagree that the two forms should be named differently, it’s even > more confusing that if you use after() you get one clock and at() the other. > Also when we will add a 3rd

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

> On 10 Jul 2016, at 14:41, Andrew Trick via swift-evolution > wrote: > > I'm revising this proposal based on last week's feedback. A few of the > additive APIs are removed and a number of UnsafePointer and > UnsafeRawPointer methods are renamed. > > Here is a PR

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> On 7 Jul 2016, at 23:28, John McCall via swift-evolution > wrote: > >> On Jul 7, 2016, at 3:26 PM, Chris Lattner via swift-evolution >> wrote: >>> On Jul 7, 2016, at 10:58 AM, Vladimir.S via swift-evolution >>>

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On 6 Jul 2016, at 18:09, Douglas Gregor wrote: > >> On Jul 5, 2016, at 10:35 PM, Ben Rimmington > > wrote: >> >>> On 5 Jul 2016, at 21:41, Douglas Gregor >> > wrote: >>>

  1   2   >