Re: [swift-evolution] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

> On 21 Jul 2016, at 18:02, Michael Gottesman wrote: > > This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore > to the Objective C overlay. The reason to do this is that ideally StdlibCore > would not have any code specific to ObjC in it. This is a small step that we >

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

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 clock to dispatch, it just st

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 for the revision. Note that th

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 >>> wrote: >>> >>> I didn't expect this is allowed(with warning): >>> >>> try pr

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: >>> The following comment is incorrect, AFAIK. The `helpAnchor`

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

> On 5 Jul 2016, at 21:41, Douglas Gregor wrote: > >> The following comment is incorrect, AFAIK. The `helpAnchor` is the name >> attribute of a HTML anchor element. >> >> /// A localized message providing "help" text if the user requests help. >> var helpAnchor: String? { get } > >

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

> On 6 Jul 2016, at 01:02, Douglas Gregor wrote: > >> On Jul 5, 2016, at 5:00 PM, Ben Rimmington wrote: >> >> >> >> The new protocols could be combined into a single CustomNSError protocol. >> This would

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

The new protocols could be combined into a single CustomNSError protocol. This would mirror the NSError class APIs, which are being customized. Instead of using NSError.setUserInfoValueProvider(forDomain:pro

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

If uses NS_EXTENSIBLE_STRING_ENUM for `domain` names and `userInfo` keys, would a generic type (cf. DispatchSpecificKey) also be possible? FOUNDATION_EXPORT NSErrorUserInfoKey const NSStringEncod

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

Alternatives: precedencegroup MultiplicativePrecedence : left where Self > AdditivePrecedence precedencegroup MultiplicativePrecedence { Self > AdditivePrecedence

Re: [swift-evolution] [Proposal] Sealed classes by default

> On 1 Jul 2016, at 17:47, John McCall wrote: > > I don't think we'd ever use a compound keyword that starts with public; > we'd just separate them and say that the second half can only be present > on a public declaration, or do this parenthesized syntax. The `super` keyword could be reused:

Re: [swift-evolution] Notification.Name

[Cc: Michael Ilseman] > On 30 Jun 2016, at 03:13, Brent Royal-Gordon via swift-evolution > wrote: > > Not 100% sure this belongs here, but I'll bite. > > The new `Notification.Name` type is a beautiful application of SE-0033 > "Import Objective-C Constants as Swift Types"[1] which removes a l

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On 27 Jun 2016, at 14:37, Xiaodi Wu wrote: > > DictionaryLiteral seems fine to me; it's as much a dictionary as ArrayLiteral > is an array, right? The `DictionaryLiteral` *structure* isn't a hash table. It's an array of key-value pairs, and allows duplicate keys. Entries are accessed by thei

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

CORRECTIONS: Find:"ExtendedGraphemeClusterConvertible" Replace: "ExtendedGraphemeClusterLiteralConvertible" Find:"StringInterpolationLiteralConvertible" Replace: "StringInterpolationConvertible" Find:"StringLiteralLiteral" (x5) Rep

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

> On 22 Jun 2016, at 20:02, Kenny Leung via swift-evolution > wrote: > > I think it would be OK if the transparent bridging called cString(using:) > itself, and the whole thing would fail if the conversion fails. But the cString(using:) method is from Foundation, and using UTF-8 should alway

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

> On 22 Jun 2016, at 17:37, Kenny Leung via swift-evolution > wrote: > > What does surprise me is that Swift String bridges directly into “char *” > arguments in C as nul-terminated C strings, apparently preserving unicode and > all. I can find nothing on bridging to “char *” in “Using Swift

Re: [swift-evolution] [Discussion] Design guideline rule for `:`

> On 22 Jun 2016, at 12:40, Adrian Zubarev via swift-evolution > wrote: > > Should there be a design guideline rule for colons : in Swift? > The standard library team (and Xcode generated interfaces) chose the first style for inheritance and where clauses (using the colon like an infix ope

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> On 22 Jun 2016, at 02:15, Shawn Erickson via swift-evolution > wrote: > > Curious on the possibility of something like the following to denote a no > return function? > > func foo() -> ! See "Diverging functions" in "The Rust Programming Language":

Re: [swift-evolution] Make UUID conform to RawRepresentable

> On 21 Jun 2016, at 01:53, Alsey Miller via swift-evolution > wrote: > > I’m the developer of PureSwift/SwiftFoundation on GitHub, and I originally > wrote that library after WWDC 2015 because I did not expect Apple to release > an Open Source version of Foundation, and also because Foundati

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

Alternative names: func infiniteLoop() -> _ { // Use an underscore instead? while true {} } func infiniteLoop() -> Unreachable { while true {} } func infiniteLoop() -> Unreachable { while t

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> On 20 Jun 2016, at 15:44, Stephen Canon wrote: > > At some danger of going off on a tangent, I should point out that DEC64 has > very little to recommend it. It’s not much more efficient performance-wise > than IEEE-754 decimal types and has significantly less exponent range (it > effectiv

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

I hope it's not too late to submit a proposal. [stdlib/public/core/FloatingPointTypes.swift.gyb] public struct Float32: BinaryFloatingPoint public struct Float64: BinaryFloatingPoint public struct

Re: [swift-evolution] LibDispatch : access to current queue, or queue name

> On 20 Jun 2016, at 10:14, Gwynne Raskind wrote: > > dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far as > I can see, and I can see uses in non-debugging contexts (logging is the > obvious one) for knowing the current queue’s label (without also allowing the > error

Re: [swift-evolution] LibDispatch : access to current queue, or queue name

> On 19 Jun 2016, at 23:52, Jérôme Duquennoy via swift-evolution > wrote: > > With the release of swift 3, The interface to libDispatch has evolved quite a > lot, to a much cleaner, object oriented interface. > There seems to be one feature that is no longer available : > In swift 2, it was po

Re: [swift-evolution] Bitshift operators

> On 18 Jun 2016, at 02:25, Dave Abrahams via swift-evolution > wrote: > > on Fri Jun 17 2016, Ben Rimmington wrote: > >> >> >>> **In initializers that perform full-width type conversions, omit the >>> first argument la

Re: [swift-evolution] [Pitch] Allow use of the name

Tony Allevato wrote: > It never even occurred to me that "case _:" would work as a replacement for > default, but it does even today—and now that I've seen it, it makes total > sense. I could definitely get behind a proposal to remove "default" as a > keyword from the language entirely in favor of

Re: [swift-evolution] Bitshift operators

> **In initializers that perform full-width type conversions, omit the > first argument label**, e.g. `Int64(someUInt32)` OptionSet could add `init(_ rawValue: RawValue)` to reduce boilerplate: struct FooOptions: Op

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

Ben Rimmington wrote: > William Shipley wrote: > > > I may be missing something, but I don’t understand how to get the behavior > > of dispatch_once() without a bunch more code in cases in which I was using > > it to initialize “lazy-ish" instance variables. > > In Objective-C, the `dispatch_once_

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

William Shipley wrote: > I may be missing something, but I don’t understand how to get the behavior > of dispatch_once() without a bunch more code in cases in which I was using > it to initialize “lazy-ish" instance variables. In Objective-C, the `dispatch_once_t` predicate *must* be a static or

Re: [swift-evolution] Bitshift operators

Brent Royal-Gordon wrote: > While I was watching WWDC videos today, I noticed that there's > a bit of annoying boilerplate in OptionSet specifications, and > set out to get rid of it. Basically, what I'd like to do is this: > > extension OptionSet where RawValue: Integer { > init(b

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Adrian Zubarev wrote: > Yes please, current Swift 3 Snapshot translated a lot of > C functions from not optionals to optionals just because > let and var works correctly on UnsafeMutablePointer’s. I think this is due to: * "SE-0055: Making pointer nullability explicit"

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

Brent Royal-Gordon wrote: > Currently, StringInterpolationConvertible only offers an > `init(stringInterpolationSegment: T)` initializer. > That means you absolutely *must* permit any type to be > interpolated into your type's string literals. It can be explicitly marked unavailable. extension L

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Erica Sadun wrote: > public func timetest(_ note: String, block: () -> Void) { > let date = NSDate() > block() > let timeInterval = NSDate().timeIntervalSince(date) > print(note); print("Elapsed time: \(timeInterval)") > } For performance testing, it might be better to use: * XCT

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

Joe Groff wrote: > ## Impact on existing code > > The number of `@noreturn` functions in the wild is fairly small, and all of > them I can find return `Void`. It should be trivial to migrate > existing `@noreturn` functions to use `-> NoReturn`. Clang allows `_Noreturn` [C11] and `__attribute__((

Re: [swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

Michael Ilseman wrote: > The biggest issue with the proposal as written is with importing a typedef > as an enum. Enums do not allow us to control the underlying storage, > and thus we would constantly be paying a bridging cost in its use. > [...] > The second issue concerns importing bridged type

Re: [swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

Michael Ilseman wrote: > The biggest issue with the proposal as written is with importing a typedef > as an enum. Enums do not allow us to control the underlying storage, > and thus we would constantly be paying a bridging cost in its use. > [...] > The second issue concerns importing bridged type

Re: [swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

SE-0033 and SE-0044 are already "Implemented in Swift 3" according to both the proposals and the README, but not according to the bug tracker: (I can't find a bug report for SE-0033). The exa

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

Trent Nadeau wrote: > ### Imported C/Objective-C APIs > > Per the Core Team, most Cocoa closure/block parameters are escaping > (e.g., delegates). As such the Clang importer will automatically add > the `@escaping` annotation to closure/block parameters encountered in > imported Objective-C APIs u

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

Instead of LosslessStringConvertible, could the existing Streamable be used? extension String { public init(_ streamable: T) { self.init() streamable.write(

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

n McCall wrote: > >> On Jun 3, 2016, at 5:31 PM, Ben Rimmington via swift-evolution >> wrote: >> John McCall wrote: >> >>> I think that's a very promising way of thinking about literals. Writing >>> a literal creates a notional value whose ty

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

John McCall wrote: > I think that's a very promising way of thinking about literals. Writing > a literal creates a notional value whose type is the informal, infinite- > precise type of all integer/FP/collection/etc. literals, which (1) can be > implicitly converted to any type that implements th

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

+1 I think the new guard/if/while grammar is an improvement. We have a limited number of ASCII punctuation characters, and the semicolon is currently underused in Swift. -- Ben _

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

Stephen Canon wrote: > Making `Float` be an alias of `Float64` would just confuse people > coming from a C-family language (as commonly implemented). To avoid confusion, and to allow for decimal floating-point types: [st

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

Dave Abrahams wrote: > > Erica Sadun wrote: > > > The whole discussion started because ArrayLiteralConvertible meant > > "can be initialized from Array literal", and not "can be converted to > > array literal", which is what nearly everyone this was presented to in > > an informal study thought it

[swift-evolution] StringInterpolationConvertible and StringLiteralConvertible inheritance

StringInterpolationConvertible inheritance of StringLiteralConvertible would allow "static-string" and \(string-expression) segments to be differentiated. /// For example, `"\(paragraph)" as HTML` would invoke: /// /// HTML.init(stringInterpolation: /// HTML.init(stringLiteral: ""), /// HT

Re: [swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

Re: UPDATED APPROACH ## Initializable +1 although the existing -Convertible suffix isn't bad. (ExtendedGraphemeClusterLiteral could also be renamed to CharacterLiteral). ## Representable +1 for the Custom[Debug]StringR

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

> On 12 May 2016, at 19:03, Matt Wright wrote: > > Are you talking about ambiguity at a compiler level, or in human-reading? I meant ambiguous for people familiar with libdispatch. For example, the

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

## Type Names I was going to suggest unprefixed type names, but having to qualify both `Dispatch.Data` and `Foundation.Data` would be an issue. If libdispatch had originally been part of Foundation, y

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

+1 to dropping the NS prefix; type names are more readable. However: * AppKit, CoreData, and TextKit will still use the NS prefix. * Prefixed names (in all frameworks) are more "googleable". * Should depr

Re: [swift-evolution] Mutability for Foundation types in Swift

The proposal looks great. ## Introduction Broken link: -- ++ ### New Value T

Re: [swift-evolution] [Review] SE-0061: Add Generic Result and Error Handling to autoreleasepool()

+1. I believe the proposal should be accepted. However, cross-platform libraries would still need to write: #if os(OSX) || os(iOS) || os(tvOS) || os(watchOS) import func ObjectiveC.autorelease

Re: [swift-evolution] Properties with parameters

Tim Vermeulen via swift-evolution writes: > Properties are great. They allow us to write the more naturally looking > > myButton.hidden = true > > instead of > > myButton.setHidden(true) > > However, they don't take any parameters. That’s why we still have to write > > myButton.setImage(myIm

Re: [swift-evolution] [Proposal] Custom operators

Антон Жилин: > No new suggestions have come in 2 days, and so I have created a pull request! > https://github.com/apple/swift-evolution/pull/253 1. Assignment operators in Swift 2.2 have an `assignment` keyword: infix operator += { associativity right precedence 90 assignment } 2. If assig

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Re: "Completing the Swift 3 range operator suite" The proposed operators (<.. and <.<) are not allowed by Swift 2.2 lexer grammar:

Re: [swift-evolution] [Proposal] Custom operators

Another way to eliminate numerical precedence is by using keywords: infix operator << { associativity none exponentiative } infix operator * { associativity left multiplica

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

Would `isOptimized` and `isOptimizedUnchecked` be useful, and also easier to specify? > On 15 Mar 2016, at 17:28, Jordan Rose via swift-evolution > wrote: > > What is a "debug build"? Is it one where testing is enabled? Where the > optimization level is -Onone? (We've talked about having an -

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

> We decided to use a Swift-based format for the manifest because we believe it > gives developers the best experience for working with and describing their > project. The

Re: [swift-evolution] [Revision] SE-0034 - Disambiguating Line Control Statements from Debugging Identifiers

> On 14 Mar 2016, at 22:30, Dave Abrahams via swift-evolution > wrote: > > on Fri Mar 11 2016, Chris Lattner wrote: > >> This provides syntax that looks like an imperative function call that >> affects the logical source location at that point in the file. > > FWIW, to me it looks like a dec

<    1   2