Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

Hi Mike, 2017-10-15 14:55 GMT+02:00 Mike Kluev : > On 15 October 2017 at 13:35, Geordie Jay wrote: > >> Also we're not talking about whether the Bool itself is discardable. For >> example, it makes no sense to write: >> >> *let something: discardable Bool

Re: [swift-evolution] How does "Sequence.joined" work?

Daryle Walker via swift-evolution schrieb am Di. 8. Aug. 2017 um 21:25: > On Aug 8, 2017, at 12:35 AM, Félix Cloutier > wrote: > > All this means is that `joined()` does not create an array that contains > the new result. It's only as magic

Re: [swift-evolution] final + lazy + fileprivate modifiers

I am glad you mention the "protected" scope. For me the private keyword is mostly just frustrating, precisely because I expect it to act in the way you describe "protected" - but it doesn't. This is probably because all of projects at my organisation (regardless of language) have files of about

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

> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution > >: > > >> What is your evaluation of the proposal? > Personally I’m a -1; I’d prefer to see the NS prefix remain on types that > have been translated automatically with

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

> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution > >: > > >> What is your evaluation of the proposal? > Personally I’m a -1; I’d prefer to see the NS prefix remain on types that > have been translated automatically with

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

> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution > >: > > >> What is your evaluation of the proposal? > Personally I’m a -1; I’d prefer to see the NS prefix remain on types that > have been translated automatically with

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

Joe Groff <jgr...@apple.com> schrieb am Mo., 9. Mai 2016 um 22:16: > > > On May 9, 2016, at 12:38 PM, Geordie Jay via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I read this proposal and I'm a bit unsure what its purpose would be: >

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

I read this proposal and I'm a bit unsure what its purpose would be: Basically you want to prevent UnsafePointer(UnsafePointer) conversions and/or vice-versa? And you'd achieve this by replacing UnsafePointer with UnsafeBytePointer that has no bound pointer type? In one sense the change seems