Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-evolution > wrote: > > > I’ve read through the last couple of Swift (sub)Module proposals put forward, > and since my particular use-cases for a sub-module solution seemed to be > under-served by them, I’ve

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 4, 2017, at 8:12 AM, Jean-Daniel <mail...@xenonium.com> wrote: > >> >> Le 3 mars 2017 à 23:21, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >>> >>

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

Sent from my iPad > On Mar 4, 2017, at 10:09 AM, Rien <r...@balancingrock.nl> wrote: > > >> On 04 Mar 2017, at 16:01, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I have updated this proposal with a few more re

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

Sent from my iPad > On Mar 4, 2017, at 11:35 AM, Charles Srstka via swift-evolution > wrote: > >> On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution >> wrote: >> >> I encountered this precise memory leak in my code a few days

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

Sent from my iPad > On Mar 9, 2017, at 2:31 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan wrote: >> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to >> incorporate some of the

Re: [swift-evolution] [Draft] Anonymous Enum Cases

+1. Combining this with overloaded cases will be very nice for some kinds of enums. Sent from my iPad > On Mar 8, 2017, at 9:09 PM, Daniel Duan via swift-evolution > wrote: > > Hi all, > > During review for the first revision of SE-0155, Dave Abraham suggested

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

Sent from my iPad > On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution > wrote: > > I think the fact that the type checker permits ‘final’ to appear inside > protocol extensions is an oversight and this probably does not even warrant a > proposal. I

Re: [swift-evolution] [Idea] Generic associated types

This is a really important feature IMO, but as others have pointed out it basically amounts to higher-kinded types. I would love to be wrong about this but I am reasonably sure this is out of scope for Swift 4 (otherwise I would be working on a proposal already). Sent from my iPad > On Mar

Re: [swift-evolution] [Idea] Generic associated types

> On Mar 12, 2017, at 3:23 PM, Karl Wagner wrote: > > >> On 12 Mar 2017, at 14:32, Matthew Johnson > > wrote: >> >> This is a really important feature IMO, but as others have pointed out it >> basically amounts to

Re: [swift-evolution] Swift null safety questions

Sent from my iPad On Mar 13, 2017, at 6:35 PM, Brent Royal-Gordon via swift-evolution wrote: >> On Mar 12, 2017, at 12:20 PM, Austin Zheng via swift-evolution >> wrote: >> >> Otherwise, if you really need to build a web server

Re: [swift-evolution] [Draft] Really Simple Submodules

Sent from my iPad > On Mar 6, 2017, at 1:39 AM, Robert Widmann via swift-evolution > wrote: > > If this were a problem that could be fixed by tooling, you'd be submitting > this proposal against the package manager. > > It's important to note I'm approaching this

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 4, 2017, at 9:56 AM, Karim Nassar wrote: > > >> On Mar 3, 2017, at 5:21 PM, Matthew Johnson > > wrote: >> >>> >>> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-evolution >>>

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

t. ;) > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 4. März 2017 um 20:10:56, Matthew Johnson via swift-evolution > (swift-evolution@swift.org) schrieb: > >> >> >> Sent from my iPad >> >> > On Mar 4, 2017, at 10:09

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 5, 2017, at 1:29 PM, Karim Nassar via swift-evolution > wrote: > > > >> On Mar 5, 2017, at 2:06 PM, Xiaodi Wu > > wrote: >> >> Punycode would readily cover your first issue about legal identifier >>

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 5, 2017, at 9:10 AM, Rien wrote: > > >> On 05 Mar 2017, at 15:52, Karim Nassar via swift-evolution >> wrote: >> >> >>> On Mar 4, 2017, at 2:54 PM, Matthew Johnson wrote: >>> On Mar 4, 2017, at

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 5, 2017, at 8:52 AM, Karim Nassar wrote: > > >> On Mar 4, 2017, at 2:54 PM, Matthew Johnson > > wrote: >> >>> >>> On Mar 4, 2017, at 9:56 AM, Karim Nassar >>

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

> On Mar 5, 2017, at 11:12 AM, Daniel Leping via swift-evolution > wrote: > > I'm not proposing syntax right now. Rather approach. Should we make ANY > capturing explicit? I don't know. Maybe someone has a stronger opinion here. I think that would be way too

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

+1. Removing this magic is a good idea. > On Mar 1, 2017, at 10:11 PM, Joe Groff via swift-evolution > wrote: > > I’d like to investigate separating Objective-C bridging from the behavior of > the as/as?/is operator family again for Swift 4. Last year, I proposed

Re: [swift-evolution] [Discussion] Simplifying case syntax

Sent from my iPad > On Feb 28, 2017, at 2:17 PM, Erica Sadun wrote: > > >> On Feb 28, 2017, at 12:19 PM, Matthew Johnson wrote: >> >> --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812 >> Content-Transfer-Encoding: quoted-printable >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

> On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution > wrote: > > A good and necessary enhancement. My only objection is to the ordering > rules—I'm not convinced that they pull their weight, especially given that > typealiases can be used to

Re: [swift-evolution] [Discussion] Simplifying case syntax

I agree that the ambiguity created by moving `let` outside the local binding context is problematic. I alway place `let` immediately alongside the binding for this reason. In design 2 do you disallow matching a value using an existing name? If so, how do users match values bound to an

Re: [swift-evolution] [Draft] scope-based submodules

> On Mar 1, 2017, at 12:55 AM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Feb 24, 2017, at 11:34 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Scope-based submodules >> >>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

>> On Wed, Feb 22, 2017 at 10:10 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>>> On Feb 21, 2017, at 11:54 PM, Robert Widmann <devteam.cod...@gmail.com> >>>> wrote: >>>&g

Re: [swift-evolution] [Draft] scope-based submodules

:55, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Feb 24, 2017, at 11:34 AM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.o

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

Sent from my iPad > On Mar 2, 2017, at 6:56 PM, Tony Allevato via swift-evolution > wrote: > > newtype feels like a leaky abstraction. Since the new type carries all the > protocol conformance and members of the original type, in your example, I > could add or

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

> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution > wrote: > > I’m concerned that we will have access control changes in a future version > yet again, when light-weight modules, or other type of enforced namespace is > introduced. Does the core team

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

> On Apr 5, 2017, at 6:01 PM, Douglas Gregor wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > > > > Hello Swift community, > >

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

> On Mar 21, 2017, at 10:57 AM, Drew Crawford via swift-evolution > wrote: > > > >> > I’m not arguing that it is less or more than a majority. I’m just saying >> > that we’ve seen a lot of talk against the original change. > > This proposal asks us to balance the

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

> On Mar 21, 2017, at 11:24 AM, Colin Barrett > wrote: > > I'm not sure I follow. What do you mean "which strategy to use for a given > encoding"? IMO there should be at most one implementation of Coding / > Decoding for a particular type. So the way you'd say "I

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

> On Mar 20, 2017, at 9:33 PM, Greg Parker via swift-evolution > wrote: > > >> On Mar 20, 2017, at 4:54 PM, Douglas Gregor > > wrote: >> >> Hello Swift community, >> >> The review of SE-0159 "Fix Private Access

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

> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution > wrote: > > > > On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution > > wrote: > > Here's what I mean: Suppose I have a

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

> On Apr 7, 2017, at 1:50 PM, Joe Groff via swift-evolution > wrote: > > >> On Apr 7, 2017, at 11:48 AM, John McCall wrote: >> >>> On Apr 7, 2017, at 1:40 PM, Joe Groff wrote: On Apr 7, 2017, at 10:20 AM, John McCall via

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

> On Apr 7, 2017, at 9:48 AM, David Hart via swift-evolution > wrote: > >> >> On 7 Apr 2017, at 15:41, BJ Homer via swift-evolution >> > wrote: >> >> -0.5 >> >> SE-0159 was rejected because it was

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

> On Apr 7, 2017, at 10:32 AM, BJ Homer wrote: > > > On Apr 7, 2017, at 9:23 AM, Matthew Johnson > wrote: > >> The most common thing is to have some stored properties that are private and >> include a handful of

Re: [swift-evolution] SE-0171: Reduce with inout

, at 9:05 PM, David Sweeris <daveswee...@mac.com> wrote: >>> >>> >>>> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>>> • What is your

Re: [swift-evolution] SE-0171: Reduce with inout

> On Apr 17, 2017, at 4:59 PM, Jaden Geller <jaden.gel...@gmail.com> wrote: > >> >> On Apr 17, 2017, at 2:37 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 10, 2017, at 7:46 AM, James Froggatt via swift-evolution > wrote: > > Since it seems to have been lost in the noise, I want to second with support > for Xiaodi's syntax of having `default` appearing in the enum declaration > itself. > > It's much clearer

Re: [swift-evolution] Enums and Source Compatibility

Sent from my iPad > On Aug 9, 2017, at 12:15 PM, Tony Allevato via swift-evolution > wrote: > >> On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution >> wrote: >> (Now with more mailing lists in the "to" field!) >>> On Aug

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 10, 2017, at 9:25 AM, Vladimir.S <sva...@gmail.com> wrote: > > On 10.08.2017 16:46, Matthew Johnson via swift-evolution wrote: >>> On Aug 10, 2017, at 7:46 AM, James Froggatt via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolutio

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

> > • What is your evaluation of the proposal? Very large +1 in general. I really wanted to see this happen in Swift 4. I’m very happy that it’s up for review right at the beginning of the Swift 5 process. That said, I do think the concern others have voiced regarding implicit

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

> On Jul 25, 2017, at 4:02 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > Default values for associated types are approved for Swift 4. They just > haven’t been implemented. Ahh, I had forgotten that. Thanks for clarifying! :) > > > On Tue, Jul 25, 2017 at 16:0

Re: [swift-evolution] Idea: Exposing _JSONEncoder and _JSONDecoder functionality

> On Jul 25, 2017, at 2:08 PM, David Hart via swift-evolution > wrote: > > >> On 25 Jul 2017, at 18:45, Itai Ferber via swift-evolution >> > wrote: >> >> Hi Morten, >> >> This is something we’ve

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

> On Jul 25, 2017, at 3:26 PM, David Sweeris via swift-evolution > wrote: > > > On Jul 25, 2017, at 12:38, Robert Bennett via swift-evolution > > wrote: > >> Currently if you have the following enum: >>

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

Sent from my iPad > On Jun 30, 2017, at 12:24 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution >> wrote: >> >> Using an operator to provide feedback on the context

Re: [swift-evolution] explicitly mark synthesized init as public

> On Jul 6, 2017, at 10:17 AM, Benjamin Spratling via swift-evolution > wrote: > > Often I want to separate my data model into a separate framework from my UI. > This enables separation of data and logic tests from UI tests. And sharing a > common data model

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 27, 2017, at 2:49 PM, David Hart via swift-evolution > wrote: > > >> On 27 Jun 2017, at 20:23, Dave DeLong via swift-evolution >> > wrote: >> >> Also a +1 from me. This is something I always put

Re: [swift-evolution] [pitch] Comparison Reform

I mentioned unums on the list about a year ago. Steve Canon replied with some thoughts: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016889.html . > On Apr 27, 2017, at 4:26 PM,

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, Thanks for bringing this topic up again! I’m glad to see it will receive attention in Swift 5. I agree with the semantics of your proposed direction. In terms of syntax, I continue to believe that requiring users to specify a keyword indicating open or closed *in addition* to

Re: [swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

Hi Tony. I’m really glad to see you’re brining this proposal back right away. It was a shame that it missed the deadline for Swift 4 and will be awesome to have it accepted for Swift 5. > On Aug 9, 2017, at 10:36 AM, Tony Allevato via swift-evolution > wrote: > >

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

> On Aug 18, 2017, at 2:15 PM, Chris Lattner via swift-evolution > wrote: > > >> On Aug 18, 2017, at 7:19 AM, Michel Fortin > > wrote: >> >> Great writeup. Here's a few comments about the manifesto,

Re: [swift-evolution] Fast enums (was: typed throws)

> On Aug 18, 2017, at 2:19 PM, Adrian Zubarev > wrote: > > Wasn’t Joe Groff and Daniel Duan proposing anonymous enum cases in some of > the early draft of the ‘Normalize Enum Case Representation’ proposal? > > Maybe it’s time to revive that topic. > >

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 12:05 PM, Joe Groff wrote: > > >> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution >> > wrote: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson >>

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 1:09 PM, John McCall wrote: > >> >> On Aug 18, 2017, at 10:19 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >> On Aug 18, 2017, at 1:27 AM, John McCall wrote: >> On Aug 18, 2017, at

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

> On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution > wrote: > > That's great. Thanks! Yes, excellent news! I am *really* looking forward to seeing this proposal make it into an Xcode release! > > R+ > > On 17 Aug 2017, at 00:46, John McCall

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 6:15 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPad > > On

Re: [swift-evolution] typed throws

had your own reasons for supporting typed errors in the past. What were those and why do you no longer consider them important? > > >> On Fri, Aug 18, 2017 at 6:46 PM, Matthew Johnson <matt...@anandabits.com> >> wrote: >> >>> On Aug 18, 2017, at 6:29 PM

Re: [swift-evolution] typed throws

om >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> Sent from my iPad &

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

Hi Chris, This is fantastic! Thanks for taking the time to write down your thoughts. It’s exciting to get a glimpse at the (possible) road ahead. In the manifesto you talk about restrictions on passing functions across an actor message. You didn’t discuss pure functions, presumably because

Re: [swift-evolution] typed throws

them based on this >> categorization I think I would be ok with that. Using wrapper types is not >> essential to solving the problem. >> >> Setting all of this aside, surely you had you had your own reasons for >> supporting typed errors in

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

Sent from my iPad On Aug 19, 2017, at 12:29 AM, Brent Royal-Gordon via swift-evolution wrote: >> On Aug 18, 2017, at 12:35 PM, Chris Lattner wrote: >> >>> (Also, I notice that a fire-and-forget message can be thought of as an >>> `async`

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

Sent from my iPad > On Aug 19, 2017, at 8:16 AM, Michel Fortin via swift-evolution > wrote: > >>> For instance, has Array value semantics? >> >> By the commonly accepted definition, Array does not provide value >> semantics. >> >>> You might be tempted to say

Re: [swift-evolution] typed throws

ng some kind of >>>> category value to the original error or propagating the category along >>>> with it might also work (although might be rather clunky). >>>> >>>> It is trivial to make the original error immediately available via an >>>&g

Re: [swift-evolution] typed throws

obviously subjective, but I do >>>> believe that libraries focused on a specific domain can often make >>>> reasonable guesses that are pretty close in the majority of use cases. >>>> This is especially true for internal libraries where part of the purpose &

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

Sent from my iPad > On Aug 19, 2017, at 3:29 PM, Michel Fortin wrote: > > >> Le 19 août 2017 à 11:38, Matthew Johnson a écrit : >> >> >> >> Sent from my iPad >> >> On Aug 19, 2017, at 8:16 AM, Michel Fortin via swift-evolution >>

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

Sent from my iPad > On Aug 19, 2017, at 9:33 PM, Brent Royal-Gordon > wrote: > >> On Aug 19, 2017, at 7:41 AM, Matthew Johnson wrote: >> >> Regardless of which approach we take, it feels like something that needs to >> be implicit for

Re: [swift-evolution] typed throws

Sent from my iPad On Aug 18, 2017, at 1:27 AM, John McCall wrote: >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson

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

> On Aug 18, 2017, at 9:19 AM, Michel Fortin via swift-evolution > wrote: > > Great writeup. Here's a few comments about the manifesto, actors and value > semantics specifically. > > > # About actors and data isolation > > Can I call global functions like sin(x)

Re: [swift-evolution] typed throws

Sent from my iPad > On Aug 17, 2017, at 11:58 PM, Chris Lattner wrote: > > Splitting this off into its own thread: Thanks. I considered starting a thread but decided to ask about it first in case it was considered out of scope for Swift 5. > >> On Aug 17, 2017, at

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

Sent from my iPad > On Aug 17, 2017, at 11:53 PM, Chris Lattner wrote: > >> On Aug 17, 2017, at 7:39 PM, Matthew Johnson wrote: >> This is fantastic! Thanks for taking the time to write down your thoughts. >> It’s exciting to get a glimpse at

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

required to actually conform to the protocol. > > That turns out to be pretty important when you think about edge cases. > Sometimes you don’t actually want the forwardee to conform (that’s probably > why you said internal / fileprivate). Sometimes you also don’t want the >

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

you said internal / fileprivate). Sometimes you also don’t want the forwarder to conform. IIRC, there are also cases where it cannot conform (I would have to dig up the proposal to recall the details). > > > On Fri, Jun 9, 2017 at 12:47 PM Matthew Johnson via swift-evolution &

Re: [swift-evolution] [Pitch] `let` in protocols

I wrote a draft of a partial initializer proposal back in January or February of last year. If you're thinking of re-introducing that topic you might want to take a look at it. You can find it here:

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

> On Jun 27, 2017, at 12:39 PM, Jaden Geller via swift-evolution > wrote: > > I’ve run into this issue many times in the real world as well. For example, > consider the following protocol: > > protocol OptionalType { > associatedtype Wrapped > } > > It is not

Re: [swift-evolution] Yet another fixed-size array spitball session

Sent from my iPad > On Jun 2, 2017, at 7:33 AM, Xiaodi Wu via swift-evolution > wrote: > > > On Fri, Jun 2, 2017 at 04:28 Brent Royal-Gordon via swift-evolution > wrote: >>> On May 28, 2017, at 11:37 PM, Daryle Walker via

Re: [swift-evolution] Revisiting SE-0110

Sent from my iPad > On Jun 4, 2017, at 12:16 PM, Chris Lattner via swift-evolution > wrote: > > >>> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution >>> wrote: >>> >>> >>> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic

Re: [swift-evolution] Revisiting SE-0110

Sent from my iPad > On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: >> >> What’s the status of this Chris’s double parens idea below? It garnered some >>

Re: [swift-evolution] Revisiting SE-0110

Sent from my iPad > On Jun 17, 2017, at 10:20 AM, Paul Cantrell via swift-evolution > wrote: > > Yes, agreed, the fix for Chris’s brain-bender shouldn’t revisit any of > SE-0155’s matching & labeling rules. > > How about: > > 1. Disallow labels for bare tuples

Re: [swift-evolution] [Pitch] Introduction of `weak/unowned` closures

Hi Adrian, this is pretty similar to the Guarded Closures proposal I drafted in February. This proposal needs a revision incorporating discussion feedback and some new ideas. If you’re interested, here’s a link to the original discussion thread:

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution > wrote: > > On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu > wrote: > On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution >

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 14, 2017, at 1:23 PM, Haravikk via swift-evolution > wrote: > > >> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution >> > wrote: >> >> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 12:09 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution > > wrote: > Somewhat related to this, shouldn’t it be possible to

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 2:39 PM, Xiaodi Wu wrote: > > Interesting. So you’d want `newtype Foo = String` to start off with no > members on Foo? Yeah. Previous discussions of newtype have usually led to discussion of ways to forward using a protocol-oriented approach.

Re: [swift-evolution] Ownership on protocol property requirements

Sent from my iPad > On May 7, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution > wrote: > > Today these keywords have no meaning inside a protocol, so clearly it should > be an error to use it in that context. I agree with Jordan that the error > should be on the

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

> On May 5, 2017, at 1:33 PM, Tony Allevato wrote: > > > > On Fri, May 5, 2017 at 11:07 AM Matthew Johnson > wrote: >> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution >>

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

> On May 5, 2017, at 2:16 PM, Tony Allevato wrote: > > On Fri, May 5, 2017 at 11:51 AM Matthew Johnson > wrote: >> On May 5, 2017, at 1:33 PM, Tony Allevato >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution > wrote: > > Thanks for your feedback, everybody! Thanks for continuing to drive this forward! > > I've updated the gist > to >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

> On May 8, 2017, at 4:02 PM, Tony Allevato wrote: > > On Sat, May 6, 2017 at 4:17 PM Chris Lattner > wrote: > On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

> On May 8, 2017, at 3:17 PM, Michael Ilseman via swift-evolution > wrote: > > If an extension on your type declares a hashValue property, what should be > the semantics? Is that an error (conflicts with default provided one), or is > that one used? How does

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

> On May 8, 2017, at 4:17 PM, Tony Allevato wrote: > > > > On Mon, May 8, 2017 at 2:11 PM Matthew Johnson > wrote: >> On May 8, 2017, at 4:02 PM, Tony Allevato >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

> On May 4, 2017, at 5:23 PM, Tony Allevato via swift-evolution > wrote: > > When I initially wrote an earlier version of this proposal last year, I was > imagining implicit derivation (as it is today for no-associated-value enums). > However, now that I'm deeper

Re: [swift-evolution] Enums and Source Compatibility

Sent from my iPad > On Sep 17, 2017, at 5:02 PM, Jonathan Hull wrote: > > >> On Sep 17, 2017, at 7:55 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Sep 17, 2017, at 3:37 AM, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

Sent from my iPad > On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution >> wrote: >> >> On 01.10.2017 1:18, Chris Lattner wrote: On Sep 29, 2017,

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

he concrete type. It sounds > like this discussion is trying to protect against a hypothetical problem that > hasn't happened yet and may not happen; it would be helpful to show some > motivating real-world cases where this is indeed a severe problem. >> On Thu, Sep 7, 2017 a

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

Sent from my iPad > On Sep 7, 2017, at 7:07 AM, Gwendal Roué via swift-evolution > wrote: > > Hello, > > I'm interested in this debate because I've been bitten by automatic synthesis > recently. > > I'm reading your discussion, but I don't have a strong opinion.

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 11:32 AM, Tony Allevato wrote: > > > > On Fri, Sep 8, 2017 at 8:35 AM Matthew Johnson > wrote: >> On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution >>

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution > wrote: > > Thanks for bringing this up, Logan! It's something I've been thinking about a > lot lately after a conversation with some colleagues outside of this > community. Some of my thoughts: > >

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 8, 2017, at 2:17 PM, Robert Widmann <devteam.cod...@gmail.com> wrote: > >> >> On Sep 4, 2017, at 11:35 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

Sep 8, 2017, at 2:17 PM, Robert Widmann <devteam.cod...@gmail.com >>> <mailto:devteam.cod...@gmail.com>> wrote: >>> >>>> >>>> On Sep 4, 2017, at 11:35 AM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org <mailto:

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 8, 2017, at 2:30 PM, Ben Cohen via swift-evolution > wrote: > > Hi Alejandro, > > I’m really happy to see someone pick this up. We had suggested some kind of > random support could be a goal for addition to the standard library in Swift > 4 phase 2 but

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 12:05 PM, Tony Allevato wrote: > > > > On Fri, Sep 8, 2017 at 9:44 AM Matthew Johnson > wrote: >> On Sep 8, 2017, at 11:32 AM, Tony Allevato >

<    8   9   10   11   12   13   14   >