Re: [swift-evolution] Move placement of 'throws' statement

Moving “throws” or changing it to a prefix “throwing” as was originally suggested are relatively minor, reasonable improvements. We do need to consider if it restricts future language evolution (such as potentially listing all of the thrown errors), so that’s why it’s relevant to talk a little

[swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

Looking for feedback before submitting a PR: https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/-corelibs-unsafebytes.md — Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer Proposal: SE-

Re: [swift-evolution] Move placement of 'throws' statement

hat a function can throw. If that is something that > might happen in the future, moving the `throws/throwing` to the front would > add a significant amount of noise before the function name. > > > On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution > <swift-evolution@swift.org <mai

Re: [swift-evolution] Move placement of 'throws' statement

I agree that this could do with revision. It looks particularly ugly when you’re dealing with throwing closures. Recently I had a signature like: public func scan(length: File.ByteOffset.Stride?, by frameSize: File.ByteOffset.Stride, with handler: (_

Re: [swift-evolution] Add wrappers for allocWithTailElems_{n} routines

> On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution > wrote: > > > on Tue Dec 13 2016, Alexey Komnin > wrote: > >> Hi everyone! >> >> I really don't know whether you have discussed it

[swift-evolution] Generalised @noescape

Hi I had the need recently to mark a value-type as @noescape, but we only allow that for closure-types. I would like to propose that we allow any parameter to any function to be marked @noescape (by default, unlike closures, they would be potentially-escaping). The standard library has

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

+1. Sensible change. > On 30 Nov 2016, at 18:15, Nate Cook via swift-evolution > wrote: > > Hello all— > > This is a proposal for a fairly minor change in slicing behavior for unsafe > buffers. > > Nate > > > -- > > > This proposal changes Swift's typed

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

> On 30 Nov 2016, at 14:11, Steve Prescott via swift-evolution > wrote: > > As the original poster of this thread, I wanted to re-state the original > question: > > Should enums REQUIRE parameter names? > > Pro: The syntax would more closely match that

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

> On 29 Nov 2016, at 18:41, Tony Allevato via swift-evolution > wrote: > > Default values and overloaded cases don't (and in fact, shouldn't) be > conflated. > > I support default values for associated values but I'm not yet ready to say > I'm in favor of

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

> On 29 Nov 2016, at 14:55, Adrian Zubarev via swift-evolution > wrote: > > I’d rather would have the ability of overloading enum cases: > > enum MyEnum { > > case a > case a(Int) > case a(label: Int) > case a(Double) > } > I don’t know how

Re: [swift-evolution] [Discussion] Parameter `vector` keyword vs. triple dot prefix for variadic generics

> On 22 Nov 2016, at 11:08, Adrian Zubarev via swift-evolution > wrote: > > Hello folks, > > I’d like to revive the discussion about the Variadic generics > > feature from the

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

> On 16 Nov 2016, at 18:06, Joe Groff via swift-evolution > wrote: > >> >> On Nov 12, 2016, at 4:19 PM, David Sweeris via swift-evolution >> wrote: >> >> >>> On Nov 10, 2016, at 12:39 PM, Stephen Canon via swift-evolution >>>

Re: [swift-evolution] Symmetrical operators

> On 14 Nov 2016, at 12:48, Haravikk via swift-evolution > wrote: > > I'm a +1 on the feature, though for simply handling symmetry it's not a super > critical issue. > > > I wonder though, when you start looking at symmetry is it worth looking at > other

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On 16 Nov 2016, at 05:25, Shawn Erickson wrote: > > Again my point isn't worrying about point of calling out to the delegate but > configuring my delegator to avoid a body of work or state management that is > unneeded if the delegate doesn't care about some mix of

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On 16 Nov 2016, at 03:42, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Nov 15, 2016, at 7:27 PM, Karl via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> In Objective-C, asking whet

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

to defining an interface with an >>> extension that provides empty defaults and for each function a match bool >>> var exists to imply if it exists or not. The code accepting a delegate can >>> probe these bool vars to configure itself to efficiently operate based on &

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

not. The code accepting a delegate can >> probe these bool vars to configure itself to efficiently operate based on >> knowledge about what the delegate expects (some missing from most proposed >> solutions other then @objc optional). >> On Tue, Nov 15,

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

legate expects (some missing from most proposed solutions > other then @objc optional). > On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On 15 Nov 2016, at 12:22, Haravikk v

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution > wrote: > > >> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution >> > wrote: >> >> >>> On Nov 14, 2016, at 22:51 , Charlie Monroe via

Re: [swift-evolution] [Pitch] Nil struct

-1 Personally, I don’t like writing “nil” at all. In my understanding of Swift, “nil” is simply a C-like shorthand for "Optional.none”. If the compiler can’t infer T (such as “let a = nil”), it should fall-back to Optional.none; I’m very surprised that this isn’t the case currently. There is

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On 2 Nov 2016, at 20:54, Slava Pestov wrote: > >> >> On Nov 2, 2016, at 8:32 AM, Paul Cantrell wrote: >> >> >>> On Oct 24, 2016, at 4:43 PM, Slava Pestov wrote: >>> >>> On Oct 24, 2016, at 8:12 AM, Paul Cantrell

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On 25 Oct 2016, at 00:06, Karl wrote: > > >> On 24 Oct 2016, at 20:23, Jonathan Hull via swift-evolution >> > wrote: >> >>> FWIW, in almost all the situations where I’ve wanted to nest types

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On 24 Oct 2016, at 20:23, Jonathan Hull via swift-evolution > wrote: > >> FWIW, in almost all the situations where I’ve wanted to nest types inside >> protocols and generic types, it’s only as a namespacing convenience. Most >> often, it’s an enum type that’s

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> That option should not be disallowed. Here is a simple example you might >>>> want to build at some point: >>>> >>>> protocol ProtocolName { >>&g

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

wift.org>> wrote: >>> >>> That option should not be disallowed. Here is a simple example you might >>> want to build at some point: >>> >>> protocol ProtocolName { >>> >>> associatedtype AssociatedType >>> } >>>

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

t;> struct InnerType {} >> } >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution >> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) s

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

t; struct InnerType {} > } > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution > (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: > >> Is your vision t

Re: [swift-evolution] Import Conditionals

I disagree. What about when you need to disambiguate? Currently you’d need to use ‘Darwin.connect(...)’ or ‘Glibc.connect(…)’. Merging them both in to one ‘Libc’ module would make that much easier. > On 18 Oct 2016, at 01:07, Sean Alling via swift-evolution > wrote:

[swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

I was just doing some googling, turns out there was a discussion about nesting protocols in other types that seemed to go positively a long time ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html

Re: [swift-evolution] Tuples as RawRepresentable

> On 16 Oct 2016, at 00:33, Haravikk via swift-evolution > wrote: > > >> On 15 Oct 2016, at 18:21, Nevin Brackett-Rozinsky >> > >> wrote: >> >> Tuples cannot conform to protocols, so

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

Done. https://bugs.swift.org/browse/SR-2963. > On 14 Oct 2016, at 22:42, John McCall <rjmcc...@apple.com> wrote: > >> On Oct 11, 2016, at 12:04 AM, Karl via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] Tuples as RawRepresentable

> On 14 Oct 2016, at 19:56, Haravikk wrote: > > Huh, see, that's why I posted the thread; I didn't know you could do it that > way (I've been trying the RawRepresentable part as its own type). > In that case yes, it seems like all that's need is an expansion of

Re: [swift-evolution] [Proposal] Enums with stored properties

> My point is that, IMO, this is all I want. Thus what I’m implying is that > there’s probably not any ABI impact to (IMO) “fix” enums with associated > values, and so I don’t know why this discussion keeps going on and veering > into (what seems to me to be) overly complex territory when many

Re: [swift-evolution] [Proposal] Enums with stored properties

I disagree. I find the first better in a number of respects (although there are certainly things you could do to optimise legibility). Firstly, I can more clearly see all of the various file errors. I can easily see how many there are, which associated values they take, etc. That’s important

Re: [swift-evolution] [Proposal] Enums with stored properties

On Wed, Oct 12, 2016 at 10:07 AM, Karl via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Not at all - his proposal looks like the enum cases have an associated value, > when that is exactly what you _don’t_ want. It’s wasted storage beca

Re: [swift-evolution] [Proposal] Enums with stored properties

Not at all - his proposal looks like the enum cases have an associated value, when that is exactly what you _don’t_ want. It’s wasted storage because they have a handful of known values. It’s a PITA, I get it, I go through it all the time, too; but really this is the very definition of a

Re: [swift-evolution] [Proposal] Enums with stored properties

You can already use structs as raw types. You just have to implement the RawRepresentable conformance yourself. RawRep doesn’t affect the enum’s storage, and the shorthand syntax we’ve got saying “case a = 42” and so on is just for the compiler to synthesise a couple of switch statements. The

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution > wrote: > > Right. The question is whether we *need* to add stored properties > out-of-module, and what the use case for that is. To me it seems that adding > them in-module is by far the more common

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

> On 11 Oct 2016, at 08:49, Benjamin Spratling wrote: > > Howdy, > The error message is not saying that aFunction throws, it says “??" might > throw. After all, you supplied a ()rethrows->(Int) to it as its second > argument, which is wrapping a ()throws->Int,

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

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

Re: [swift-evolution] private & fileprivate

> On 8 Oct 2016, at 21:01, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On 8 Oct 2016, at 16:47, Braeden Profile &l

Re: [swift-evolution] private & fileprivate

ggest will give a lot of flexibility without - I > think - the IMHO quirkiness of friends in C++. It seems like the access > domains must? be limited to inside a module to avoid potential surprises from > outside the module? > > -Shawn > > On Sat, Oct 8, 2016 at 3:38 A

Re: [swift-evolution] associated objects

> On 28 Sep 2016, at 17:26, Jay Abbott via swift-evolution > wrote: > > I have implemented Associated Objects (and values) in pure swift here: > https://github.com/j-h-a/AssociatedObjects > > > The README is very short

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

It’s one of those issues where everybody agrees we could do better but nobody cares enough to do anything about it. In any case I think Discourse seemed to be the only real option because of mailing-list support. So I suppose they next step would be to submit a formal proposal to swift-evo on

Re: [swift-evolution] private & fileprivate

> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution > wrote: > > >> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution >> wrote: >> personally I thought `private` was fine the way it was when it meant >> `fileprivate` and I

Re: [swift-evolution] [proposal draft] new syntax to access a given case's payload

> On 27 Sep 2016, at 18:55, Joe Groff via swift-evolution > wrote: > > >> On Sep 26, 2016, at 8:51 AM, Jérôme Duquennoy via swift-evolution >> wrote: >> >> Summary >> The aim of this proposal is to offer a new syntax to ease some uses

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> On 14 Sep 2016, at 18: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] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

> On 25 Sep 2016, at 21:45, Drew Crawford wrote: > >> I think this is already part of the Generics Manifesto: >> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md >> > So is this

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

> On 24 Sep 2016, at 21:58, Drew Crawford via swift-evolution > wrote: > > This is the #1 Swift feature I have wanted for the past 2 years. > > One thing I would like to see (perhaps out of scope for this proposal) is the > natural extension for generic parameters:

Re: [swift-evolution] Source-breaking proposals?

> On 25 Sep 2016, at 18:38, Anton Zhilin via swift-evolution > wrote: > > Do I miss something, or proposals with source-breaking changes still can't be > submitted? > When will corresponsing guidelines be out? Are there any plans on that matter? >

Re: [swift-evolution] [Proposal] Normalize Unicode Identifiers

No the proposal seems to be about unicode characters in Swift source code: To ease lexing/parsing and avoid user confusion, the names of custom identifiers (type names, variable names, etc.) and operators in Swift can be composed of (mostly) separate sets of characters. In that sense, it

Re: [swift-evolution] Mark protocol methods with their protocol

I would like to make it a requirement if not inside a protocol extension which declares a conformance, and actually build the protocol name in to the member in an ABI-breaking way. We could make it additive by generating forwarding thunks from the old symbols to the new ones, but it would be

Re: [swift-evolution] Mark protocol methods with their protocol

fined in extensions, so if you want to back an implementation with one, >>> you’ll need to make its conformance explicit in the main body (or we loosen >>> that to at least extensions in the same file). >>> >>> ``` >>> // generates thunks to members of thi

Re: [swift-evolution] Mark protocol methods with their protocol

so MyComplexDataType.count —> MyComplexDataType.InternalStructure.count, >> // to account for conformance being added in later version. Can also be used >> for renamed protocols, and be tagged on individual members. >> >> @makeAvailable(as: _) >> extension MyComplexDataType : InternalStructure { >&g

Re: [swift-evolution] Mark protocol methods with their protocol

ith conformance implementation > details. > // Also, we get errors about non-conformance where we want them — > where the implementation is. > } > func doInternalMagic(at: Index) { >... > } > } > ``` > >> On 20 Sep 2016, at 2

Re: [swift-evolution] Mark protocol methods with their protocol

> On 21 Sep 2016, at 00:08, Vladimir.S <sva...@gmail.com> wrote: > > On 21.09.2016 0:28, Karl via swift-evolution wrote: >> > > I don't understand. Do you feel that this: > > class MyClass : MyProto { >var MyProto.aVariable : Int >func MyProto

Re: [swift-evolution] Mark protocol methods with their protocol

ere the implementation is. } func doInternalMagic(at: Index) { ... } } ``` > On 20 Sep 2016, at 23:46, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > I'm not sure I understand. What compiler or language support is missing for > StringCore? > On Tue, Sep 20, 2016 at 16:42

Re: [swift-evolution] Mark protocol methods with their protocol

> On 20 Sep 2016, at 23:28, Karl wrote: > > >> On 20 Sep 2016, at 18:43, Nevin Brackett-Rozinsky via swift-evolution >> > wrote: >> >> I have been following this discussion (as well as similar threads

Re: [swift-evolution] Mark protocol methods with their protocol

> On 20 Sep 2016, at 18:43, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > I have been following this discussion (as well as similar threads earlier > this year) and listening to the ideas put forth by all sides. > > It seems to me that the fundamental

Re: [swift-evolution] Mark protocol methods with their protocol

I started putting together a proposal, hopefully better explaining what I’m suggesting: https://github.com/karwa/swift-evolution/blob/patch-2/-template.md > On 17 Sep 2016, at 05:32, Xiaodi Wu

Re: [swift-evolution] Mark protocol methods with their protocol

> On 17 Sep 2016, at 05:32, Xiaodi Wu wrote: > > On Fri, Sep 16, 2016 at 20:28 Karl > wrote: >> On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution >> >

Re: [swift-evolution] Mark protocol methods with their protocol

> On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution > wrote: > > I absolutely agree that it's a problem worth solving. However, the question > is whether a particular proposed design solves the problem and avoids > previously stated weaknesses. What I'm

Re: [swift-evolution] [Pitch] mutable `newValue` in willSet

u never have to write "var newValue". In fact, what you're actually >> proposing isn't even the equivalent of "var newValue"; it's to have newValue >> be of type `inout T` instead of `T`. I think such an implicit inout has no >> precedent in Swift and w

Re: [swift-evolution] [Review] SE-0139: Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

I know the review is over, but I just wanted to chime in with something: does this extend to types which are RawRepresentable as numeric types, too? For example, Cocoa and UIKit have several option-set types which must be placed in dictionaries. Just now I tried to use

Re: [swift-evolution] Class scoped access level

> On 10 Sep 2016, at 14:16, T.J. Usiyan via swift-evolution > wrote: > > I am firmly against this. The 5 levels that we have cover us well and have > enough complexity already. You can say that again! It seems the compiler has become much stricter about it very

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

> > * What is your evaluation of the proposal? +1 > * Is the problem being addressed significant enough to warrant a >change to Swift? Yup > * Does this proposal fit well with the feel and direction of Swift? Yes, but I’m not sure about the “Unsafe” part of “UnsafeBytes” — what is

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

> On 2 Sep 2016, at 06:14, Xiaodi Wu wrote: > > Run loop modes are named by string, and as you can see in your link, > comparisons of run loop modes are by their raw value--i.e. by string. While > it's of course sensible to have a total ordering for strings, I'm skeptical

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

> On 31 Aug 2016, at 15:53, Xiaodi Wu wrote: > > Comparable makes semantic guarantees about how values of conforming types > might be ordered. You don't need `min` or `max` for that to be useful, since > it's trivial to implement using comparison operators. > > Basic

Re: [swift-evolution] PITCH: Return a subclass for a protocol method without the need for an associatedtype

> On 31 Aug 2016, at 06:10, Sitton, Yogev via swift-evolution > wrote: > > That’s was my point. > Two sets of rules for the same case in two different places. > These should be unified. > > I’ll write the proposal and create a pull request. > >> On Aug 17, 2016, at

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

> On 30 Aug 2016, at 10:18, Xiaodi Wu via swift-evolution > wrote: > > As an additive proposal, I don't think this would be in scope for the current > phase of Swift 4. > > Looking forward, though, I'm not sure this belongs in the standard library. > In general,

Re: [swift-evolution] [Late Pitch] open/public protocols

This is not a new inconsistency. We’ve known about this since “open” was first proposed. Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. Karl > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution > wrote: > > Hello dear Swift

Re: [swift-evolution] Renaming for Protocol Conformance

> On 24 Aug 2016, at 20:38, Douglas Gregor via swift-evolution > wrote: > >> >> On Aug 22, 2016, at 9:59 PM, Jonathan Hull via swift-evolution >> > wrote: >> >> Hi everyone, >> >> We talked about this

Re: [swift-evolution] [Pitch] Require Any for existentials

> On 24 Aug 2016, at 00:14, Adrian Zubarev via swift-evolution > wrote: > > The basic design is fine, but I wouldn't want to add more noise to my code. > We could keep (label: Protocol) as a shorthand form for (label: > Any) similar to Optionals. > > What's the

Re: [swift-evolution] Renaming for Protocol Conformance

> On 23 Aug 2016, at 07:39, Karl wrote: > > >> On 23 Aug 2016, at 06:59, Jonathan Hull via swift-evolution >> wrote: >> >> Hi everyone, >> >> We talked about this before when we were discussing mixins, and there seemed >> to be

Re: [swift-evolution] Renaming for Protocol Conformance

> On 23 Aug 2016, at 06:59, Jonathan Hull via swift-evolution > wrote: > > Hi everyone, > > We talked about this before when we were discussing mixins, and there seemed > to be generally positive feelings towards it as a feature for the future. I > am fairly

Re: [swift-evolution] [Idea] Typed Numerics

> On 22 Aug 2016, at 18:17, Charlie Monroe via swift-evolution > wrote: > > I've personally come across something like Nur suggested. In particular, this > is with NSTimeInterval, which is a typedef for Double. > > What I wanted to do is to make > > extension

Re: [swift-evolution] Swift Package Manager 3.0 Project Status

> On 18 Aug 2016, at 03:04, Keith Smiley via swift-evolution > wrote: > > It sounds like we may not get any heads up about any work on that level of > integration: > > https://twitter.com/jckarter/status/766072626624073729 > > Which I guess also brings up the

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

> On 19 Aug 2016, at 19:35, Andrew Trick <atr...@apple.com> wrote: > > >> On Aug 16, 2016, at 7:13 PM, Karl via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 16 Aug 2016, at 01

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

> On 11 Aug 2016, at 07:18, Chris Lattner via swift-evolution > wrote: > > >> On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> I don't know if the core team feels differently

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

> On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution > wrote: > >> On Aug 15, 2016, at 13:55, Michael Ilseman via swift-evolution >> wrote: > >> >> It seems like there’s a potential for confusion here, in that people may see

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution > wrote: > >> On Aug 16, 2016, at 5:30 PM, Xiaodi Wu > > wrote: >> >> On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution >>

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

> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution > wrote: > > Hi folks, > > I see from building the latest Swift-3.0 branch that I’m a little behind the > times and this proposal has been accepted :( > >

Re: [swift-evolution] Swiftier implementation of Measurement and Unit

> On 11 Aug 2016, at 00:51, Xiaodi Wu via swift-evolution > wrote: > > Probably swift-corelibs-dev would be the forum for that? IIUC correctly, > though, the current goal for corelibs-foundation is to vend the exact same > API as Apple Foundation. I'd also be

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

> On 9 Aug 2016, at 21:09, Dave Abrahams via swift-evolution > 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] [Review] SE-0136: Memory Layout of Values

> On 8 Aug 2016, at 04:18, Dave Abrahams wrote: > > > on Sun Aug 07 2016, Karl > wrote: > >>> * What is your evaluation of the proposal? >> >> +1 >> >> Although if I was nitpicking I prefer the name “ofInstance” (as in the >> stdlib

Re: [swift-evolution] [Review] SE-0136: Memory Layout of Values

> * What is your evaluation of the proposal? +1 Although if I was nitpicking I prefer the name “ofInstance” (as in the stdlib private function) to “ofValue”. What is the standard nomenclature? Whereas I would distinguish between “objects/instances” and “values”, I’ve started referring

Re: [swift-evolution] Swift 3.1 discussions, go?

> On 3 Aug 2016, at 05:29, Chris Lattner via swift-evolution > wrote: > > If you see such a drastic slowdown, then tat sounds like a critical > regression that you found in the latest beta. We would really appreciate a > bug report (radar or jira) with a testcase!

Re: [swift-evolution] MemoryLayout for a value

> On 6 Aug 2016, at 11:05, Adrian Zubarev via swift-evolution > wrote: > > What’s so confusing about MemoryLayout.size? > > size in this context gives you the size for the metatype of T, not the size > of T. > > If I memorize correctly: > > Size of metatypes of

Re: [swift-evolution] MemoryLayout for a value

> On 4 Aug 2016, at 06:27, Dave Abrahams via swift-evolution > wrote: > > > on Wed Aug 03 2016, Xiaodi Wu > wrote: > >> Why not just MemoryLayout.init(of instance: T), and drop the autoclosure >> magic altogether? > > My proposal

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

> On 2 Aug 2016, at 11:07, Tino Heth via swift-evolution > 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

[swift-evolution] [Idea] Specialising based on function parameter values

I’ve had this idea floating around my head for a little while, and I’m not sure if it’s either really interesting or totally absurd. Sorry if it’s not time for ideas like this yet. It’s not really a “proposal”, but it would be ABI-related I think. So, the idea: The compiler can generate

Re: [swift-evolution] Improved value and move semantics

> On 29 Jul 2016, at 18:42, Bram Beernink via swift-evolution > wrote: > > Hi all, > > Would it be possible to improve value and move semantics (performance) in > Swift? Consider this possible Swift code in a future release of Swift: > > let array1 : [String] =

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

> On 29 Jul 2016, at 18:01, Brandon Knope via swift-evolution > wrote: > > I think this just shows how familiar many of us are with this process. > > It’s fun and challenging coming up with the great ideas…but someone has to > implement it. It may not be fun…and it

[swift-evolution] [Swift 3?] Add ContiguousArray -> Array non-copying initialiser

https://github.com/apple/swift/pull/3819 > As I understand it, Array may be backed by contiguous storage (if native) or > it may be backed by some exotic NSArray subclass. We provide a related type > with stronger backing guarantees: ContiguousArray

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

> SE-0104 - Protocol-oriented integers > We > used to have a prototype implementation of this, but it was removed (by > mistake?) by @moiseev a couple of weeks ago:

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

> SE-0104 - Protocol-oriented integers > We > used to have a prototype implementation of this, but it was removed (by > mistake?) by @moiseev a couple of weeks ago:

Re: [swift-evolution] asyncAfter(deadline: ...)

> On 27 Jul 2016, at 10:23, Guillaume Lessard via swift-evolution > wrote: > > Hello, > > The newer version of the libdispatch overlay (as of 8ac413a) looks good: > thanks for your work Matt! > > It replaced async(when: ) with asyncAfter(deadline: ); however

Re: [swift-evolution] [Accepted] SE-0131: Add AnyHashable to the standard library

> On 26 Jul 2016, at 19:52, Chris Lattner via swift-evolution > wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md > > The review of "SE-0131: Add AnyHashable to the standard library" ran from > Active

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

I’d only +1 this proposal if we can perform an implicit conversion. From SE-0116: > The user model for this type would ideally align with our long-term goal of > supporting Hashable existentials directly, so the type deserves some > short-term compiler support to help us get there. I read

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

What about if we defined subclasses with the “subclass” keyword instead of “class”? So you knew the first parameter was always going to be a base class? That way we keep the single “:” everywhere else - where clauses, generic constraints lists, etc. > On 22 Jul 2016, at 15:14, Vladimir.S via

  1   2   >