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

Yes but: extension MemoryLayout { @_transparent public static func size(ofValue _: T) -> Int { return MemoryLayout.size } @_transparent public static func stride(ofValue _: T) -> Int { return MemoryLayout.stride } @_transparent public static func alignment(ofValue _: T) ->

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

On Sun, Aug 7, 2016 at 9:31 PM, Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote: > Can someone quickly explain what this new API does compared to what SE-101 > had? > > I'm trying hard to see what's being added here but my brain isn't working > > Brandon > The text of

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

Can someone quickly explain what this new API does compared to what SE-101 had? I'm trying hard to see what's being added here but my brain isn't working Brandon Sent from my iPad > On Aug 7, 2016, at 10:18 PM, Dave Abrahams via swift-evolution > wrote: > > > on

[swift-evolution] More fine tuning optimization to swift compiler

I'm not sure if this is the right channel to discuss on optimization switch We are aware the 3 options: -O -Ofast -Ounchecked As we can see, we rarely use -Ounchecked for safety reason and there aren't much info on what are the tradeoff. if there are performance reason that will need to improve

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

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 private function) to “ofValue”. The problem with “ofInstance” is that a class instance will be reported to be the same

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

+1 from me. I followed the discussion and read the proposal. It seems like a fairly straightforward solution to the problem. On Sun, Aug 7, 2016 at 9:03 PM, Karl via swift-evolution < swift-evolution@swift.org> wrote: > > > * What is your evaluation of the proposal? > > +1 > > Although if

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

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

Hello Swift community, The review of "SE-0136: Memory Layout of Values" begins now and runs through August 9th. Apologies for the short review period, but we are running up against the Swift 3 deadline. The proposal is available here:

Re: [swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

> On Aug 7, 2016, at 2:33 PM, Jacob Bandes-Storch wrote: > > extension URL { > enum Reachability { > case reachable > case notReachable(ErrorProtocol) > } > func reachability() -> Reachability > } That is excellent. Charles

Re: [swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

> On Aug 7, 2016, at 2:20 PM, Félix Cloutier wrote: > > I read it from the Mac Developer Library's documentation, which has all of > that for the Swift version too (link >

Re: [swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

If you were to design this API for Swift in the first place, you might want to do something entirely different: extension URL { enum Reachability { case reachable case notReachable(ErrorProtocol) } func reachability() -> Reachability } On Sun, Aug 7, 2016 at 12:20 PM,

Re: [swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

I read it from the Mac Developer Library's documentation, which has all of that for the Swift version too (link ). I was

Re: [swift-evolution] Location of ! in Boolean negation expressions

Moving the location of the ! will cause more readability problems, particularly with confusion with the unwrap operator, and the fact that it hides the negation operator in the middle of an expression. A simple, very easily implemented solution needs not language change for use with a guard

Re: [swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

> On Aug 7, 2016, at 1:59 PM, Félix Cloutier wrote: > > One line above the text that you quoted, you can read: > >> If this method returns false, the object pointer referenced by error is >> populated with additional information. That’s only in the documentation for the

[swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

-[NSURL checkResourceIsReachableAndReturnError:] has taken on several forms in Swift during its development, sometimes returning a Boolean and an error by reference, sometimes returning Void and using Swift’s do/try/catch system. In Swift 3, though, it appears to do both, which is weird: func

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] Pitch: URL(fileURLWithPath:) to URL(filePath:)

> Right. We’ll have some limited ability to do source breaking changes in Swift > 4, but we need to figure out how the mitigation strategy will work (in full > detail) so we know exactly what sort of changes will work. What about having additional source-breaking changes (like the one pitched