Re: [swift-evolution] [Proposal] Type Narrowing

> Le 7 nov. 2016 à 04:52, Chris Lattner via swift-evolution > a écrit : > > >> On Nov 3, 2016, at 10:04 AM, Haravikk via swift-evolution >> wrote: >> >> To avoid hijacking the guard let x = x thread entirely I've decided to try >> to

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

> On Nov 6, 2016, at 8:03 PM, Dave Abrahams via swift-evolution > wrote: >> I had a brush with Julia > as >> well. Have you >> looked at their work > > It's been a while, to be honest. > >> and the recent reworking of

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

on Sun Nov 06 2016, Hooman Mehr wrote: > Yes, this is a very important issue to consider before we freeze them. > > As part of my Swift hobby, I have worked a bit on a Swifty wrapper for > linear algebra packages That domain makes an excellent test case. > and also

Re: [swift-evolution] [Proposal] Type Narrowing

> On Nov 3, 2016, at 10:04 AM, Haravikk via swift-evolution > wrote: > > To avoid hijacking the guard let x = x thread entirely I've decided to try to > write up a proposal on type narrowing in Swift. > Please give your feedback on the functionality proposed, as

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

Yes, this is a very important issue to consider before we freeze them. As part of my Swift hobby, I have worked a bit on a Swifty wrapper for linear algebra packages and also toyed a bit with the merits of a Swift implementation of some of the related algorithms and data structures (such as

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

on Sun Nov 06 2016, Daniel Duan wrote: >> On Nov 6, 2016, at 1:20 PM, Dave Abrahams via swift-evolution >> wrote: >> >> A construct that is only conditionally unsafe >> shouldn't be spelled "unsafe" when used in a safe way, right? So this >> *seems* to argue for an

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

> On Nov 6, 2016, at 1:20 PM, Dave Abrahams via swift-evolution > wrote: > > A construct that is only conditionally unsafe > shouldn't be spelled "unsafe" when used in a safe way, right? So this > *seems* to argue for an "unsafe" keyword that can be used to label >

Re: [swift-evolution] [Proposal] Type Narrowing

> On 3 Nov 2016, at 22:56, Nevin Brackett-Rozinsky > wrote: > > Okay, I think I found an actual shortcoming that type narrowing might > address, namely mutating a property in place if it is a subtype. Here is a > small example setup: > > protocol A { var x: