Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

> On 3 May 2017, at 22:06, John McCall via swift-evolution > wrote: > >> >> On May 3, 2017, at 3:56 PM, Florent Bruneau >> wrote: >> >> >>> Le 3 mai 2017 à 17:23, John McCall a écrit : >>> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution wrote: > • What is y

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

> On May 3, 2017, at 3:56 PM, Florent Bruneau > wrote: > > >> Le 3 mai 2017 à 17:23, John McCall a écrit : >> >>> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution >>> wrote: • What is your evaluation of the proposal? >>> >>> +1. However, it's unclear to me what the dyn

Re: [swift-evolution] Replace throws with Result

> On May 3, 2017, at 3:31 AM, Jaden Geller via swift-evolution > wrote: > > To be frank, there’s no way this is happening. The rationale for Swift’s > error handling is documented > , and this > system was designed and implem

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

> Le 3 mai 2017 à 17:23, John McCall a écrit : > >> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution >> wrote: >>> • What is your evaluation of the proposal? >> >> +1. However, it's unclear to me what the dynamic enforcement will look like: >> will it trap, emit a warning, be

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

> On May 3, 2017, at 12:05 AM, Paul Cantrell via swift-evolution > wrote: > I like the spirit of the proposal. It leaves me a bit uneasy because the > practical ramifications are difficult to fully anticipate. Here follow some > questions / concerns for the proposal authors. > > (Apologies if

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution > wrote: >> • What is your evaluation of the proposal? > > +1. However, it's unclear to me what the dynamic enforcement will look like: > will it trap, emit a warning, be catchable in a debugger, ... More details on > the develo

Re: [swift-evolution] Replace throws with Result

> Le 3 mai 2017 à 16:12, Jose Manuel Sánchez Peñarroja via swift-evolution > a écrit : > >> At what cost ? Today, the error handling is barely zero-cost thanks to the >> swift calling convention. Having a generic return type will not only prevent >> calling convention optimization, but it wil

Re: [swift-evolution] Replace throws with Result

> At what cost ? Today, the error handling is barely zero-cost thanks to the > swift calling convention. Having a generic return type will not only prevent > calling convention optimization, but it will also add cost to all the return > types as they will have to embed a discriminator. I guess

Re: [swift-evolution] Replace throws with Result

> Le 3 mai 2017 à 12:06, Jose Manuel Sánchez Peñarroja via swift-evolution > a écrit : > > There is currently a discussion open about throws, but it seems that the idea > would be to add optionals to throws. In my opinion it would be much better to > just get rid of all the throw error system

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

> On May 3, 2017, at 2:09 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I definitely agree that it's a feature that _can_ be used unwisely, but the >> fact remains that it

Re: [swift-evolution] Replace throws with Result

To be frank, there’s no way this is happening. The rationale for Swift’s error handling is documented , and this system was designed and implemented *after* optionals already existed in the language. I don’t think there’s any ev

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

I should add, the reason final is inapt in this situation is at least twofold. The first is, of course, that this makes it impossible to guarantee source compatibility and offer additional functionality in a protocol extension, since any such addition would break unknowable amounts of existing cod

[swift-evolution] Replace throws with Result

There is currently a discussion open about throws, but it seems that the idea would be to add optionals to throws. In my opinion it would be much better to just get rid of all the throw error system. I think an *Result* type would provide much better error handling than the current solution: -

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

> On 3 May 2017, at 5:32 PM, Anders Ha via swift-evolution > wrote: > > So a bit of correction: generic protocol had been dismissed in the Generic > Manifesto specifically for sequences and collections, because it would permit > multiple conformances of a certain type to the same protocol wit

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

So a bit of correction: generic protocol had been dismissed in the Generic Manifesto specifically for sequences and collections, because it would permit multiple conformances of a certain type to the same protocol with different types of elements, and it is considered wrong. `Self` in a protoco

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Well, the revised integer protocols that were just approved do just that: some functions are defaults and others cannot be overridden. Smart shifts, for example, are deliberately not customization points. This is also the case for Equatable: you get to define ==, but != is not a protocol requiremen

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

@Anders, I think you can eliminate the dynamic dispatch for a struct. Using the generic parameterised syntax rather than the where clause syntax (because it is more compact and clearer): protocol Sequence { func filter(_ isIncluded: (T) -> Bool) -> Self // Note: returns Self .

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

@Brent, What aspects of the current proposal do you have reservations about? -- Howard. On 3 May 2017 at 18:09, Brent Royal-Gordon wrote: > On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I definitely agree that it's a feature that _can_ b

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution > wrote: > > I definitely agree that it's a feature that _can_ be used unwisely, but the > fact remains that it _is_ used pervasively in the standard library, and > deliberately I'm not so sure that's true. Which standard library p

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

> • What is your evaluation of the proposal? +1. However, it's unclear to me what the dynamic enforcement will look like: will it trap, emit a warning, be catchable in a debugger, ... More details on the developer-facing interface of the dynamic enforcement would be nice. > • Is the problem bei

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

Returning `Self` requires higher kinded type. Note that parameterized protocols are not the same as higher kinded types, since for the former generic protocol parameters are already bound at conformance of the static `Self` like associated types, while the later is about having a generic static