Re: [swift-evolution] ABI of throwing

I laughed! I've had the same thoughts. Sent from my iPhone > On 10 Aug 2016, at 01:22, John McCall via swift-evolution > wrote: > > Aside: I keep running into people writing things like JSON deserializers who > for some reason insist on making their lives unnecessarily difficult by > manually

Re: [swift-evolution] Binary framework distribution?

Binary framework distribution is discouraged from due to the ABI not being finalized - i.e. the framework wouldn't be compatible with Swift 4, and perhaps even with Swift 3.1. Xcode issues should be filed via Apple's radar system - http://bugreport.apple.com > On Aug 10, 2016, at 4:24 AM, 晓敏 褚

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

According to http://c9x.me/art/gthreads/intro.html I would guess so - pretty much userland threads - swapping context without kernel. > On Aug 9, 2016, at 11:07 PM, Goffredo Marocchi via swift-evolution > wrote: > > Talking about green threads, are the

Re: [swift-evolution] ABI of throwing

> On Aug 9, 2016, at 7:00 PM, Félix Cloutier wrote: > No, I fully understand this. My point is that this doesn't seem to accurately > represent the cost of exceptions. > > In a JSON parser, since the topic has been brought up, you don't have Y*P > calls that succeed and N*(1-P) calls that fail.

[swift-evolution] Binary framework distribution?

The current swift package manager has several major weak points: Incomplete Xcode compatibility. Xcode seems not supporting swift package. No pre-building information. For example, I employ swift package manager to add a framework to my project, then no information could be reached before I build

Re: [swift-evolution] ABI of throwing

No, I fully understand this. My point is that this doesn't seem to accurately represent the cost of exceptions. In a JSON parser, since the topic has been brought up, you don't have Y*P calls that succeed and N*(1-P) calls that fail. You have Y*P calls that succeed and *at most one* call that f

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

On Aug 9, 2016, at 7:21 PM, Michael Ilseman wrote: > > Please file radars for these against the offending frameworks. You can > additionally discuss them on swift-dev or swift-users, but definitely file > those radars! Will do. I just fired off about five of them, before the Radar server abrup

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

> On Aug 9, 2016, at 1:01 PM, Charles Srstka via swift-evolution > wrote: > >> On Aug 9, 2016, at 2:09 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> Hi Everybody, >> >> With another round of apologies for taking late action, we propose to >> make some deprecations, moves, and re

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

on Tue Aug 09 2016, Dave Abrahams wrote: > Hi Everybody, > > With another round of apologies for taking late action, we propose to > make some deprecations, moves, and renames. The background for these > moves is as follows: Full proposal: https://github.com/apple/swift-evolution/blob/master/p

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

on Tue Aug 09 2016, Ben Rimmington wrote: >> On 9 Aug 2016, at 20:09, Dave Abrahams wrote: >> >> Hi Everybody, >> >> With another round of apologies for taking late action, we propose to > >> make some deprecations, moves, and renames. The background for these >> moves is as follows: >> >> W

Re: [swift-evolution] ABI of throwing

> On Aug 9, 2016, at 8:19 AM, Félix Cloutier via swift-evolution > wrote: > >> “Zero cost” EH is also *extremely* expensive in the case where an error is >> actually throw in normal use cases. This makes it completely inappropriate >> for use in APIs where errors are expected in edge cases (

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

+1 > On Aug 9, 2016, at 6:57 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Aug 09 2016, Karl > wrote: > >>> On 9 Aug 2016, at 21:09, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> Hi Everybody, >>> >> >>> With another round of

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

> On Aug 9, 2016, at 10:46 AM, Erik Eckstein via swift-evolution > wrote: > >> >> On Aug 9, 2016, at 10:19 AM, Wallacy via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I believe the -O is already able to loop unroll > > correct > >> , but now C-Style loop is gone, and

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

on Tue Aug 09 2016, Karl wrote: >> On 9 Aug 2016, at 21:09, Dave Abrahams via swift-evolution >> wrote: >> >> >> Hi Everybody, >> > >> With another round of apologies for taking late action, we propose to >> make some deprecations, moves, and renames. The background for these >> moves is a

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

> On 9 Aug 2016, at 21:09, Dave Abrahams via swift-evolution > wrote: > > > Hi Everybody, > > With another round of apologies for taking late action, we propose to > make some deprecations, moves, and renames. The background for these > moves is as follows: > > We've always known that when

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

> On 9 Aug 2016, at 20:09, Dave Abrahams wrote: > > Hi Everybody, > > With another round of apologies for taking late action, we propose to > make some deprecations, moves, and renames. The background for these > moves is as follows: > > We've always known that when Swift reached ABI stability

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Talking about green threads, are they similar to fibers? http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine Sent from my iPhone > On 9 Aug 2016, at 21:59, Joe Groff via swift-evolution > wrote: > > >> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution >> w

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

+1 Sent from my iPhone > On Aug 9, 2016, at 14:09, Dave Abrahams via swift-evolution > wrote: > > > Hi Everybody, > > With another round of apologies for taking late action, we propose to > make some deprecations, moves, and renames. The background for these > moves is as follows: > > We'v

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution > wrote: > > The Rust language used to use a green thread model like Go (actually it > exposed a configurable threading interface so you could choose green threads > or OS threads). It also used segmented stacks like Go did. Over

Re: [swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

on Mon Aug 08 2016, Jacob Bandes-Storch wrote: > Hi Dave, > I just filed https://bugs.swift.org/browse/SR-2303. > > Brainstorming: is it important that the init(stringInterpolation:) and > init(stringInterpolationSegment:) requirements are on the same type? As far as I'm concerned the design sp

Re: [swift-evolution] ABI of throwing

>> “Zero cost” EH is also *extremely* expensive in the case where an error is >> actually throw in normal use cases. This makes it completely inappropriate >> for use in APIs where errors are expected in edge cases (e.g. file not found >> errors). > > Anecdote: I work with a web service that

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

The Rust language used to use a green thread model like Go (actually it exposed a configurable threading interface so you could choose green threads or OS threads). It also used segmented stacks like Go did. Over time, Rust ended up dropping the segmented stacks because it significantly complica

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

> On Aug 9, 2016, at 2:09 PM, Dave Abrahams via swift-evolution > wrote: > > > Hi Everybody, > > With another round of apologies for taking late action, we propose to > make some deprecations, moves, and renames. The background for these > moves is as follows: > > We've always known that whe

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

For matrix math, there are several projects in existence. I know of Surge and its forked cousin Upsurge, and a quick googling reveals a few more. On Tue, Aug 9, 2016 at 14:22 Maximilian Hünenberger < swift-evolution@swift.org> wrote: > I think this is a great idea! > > As Chris said we should use

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

+1. All seems reasonable to me. On Tue, Aug 9, 2016 at 14:16 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > Hi Everybody, > > With another round of apologies for taking late action, we propose to > make some deprecations, moves, and renames. The background for these > m

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

I think this is a great idea! As Chris said we should use GitHub or something else to start such a project. Does someone already has a Math library where we can discuss and commit? I'll soon push a small Math library to my GitHub repo and let you know. Best regards Maximilian > Am 03.08.2016 u

[swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

Hi Everybody, With another round of apologies for taking late action, we propose to make some deprecations, moves, and renames. The background for these moves is as follows: We've always known that when Swift reached ABI stability (now slated for Swift 4), we would be committed to supporting ma

[swift-evolution] What're the Swift team's thoughts on Go's concurrency?

I'd like to inquire as to what the Swift team thoughts on Go's concurrency model are? I'm not referring to convenience of the 'go' keyword and nor am I referring to how the language handles Channels, both of which being what most folks associate with it. Rather, I'd like to ask about the langu

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

In the alternatives section of the proposal, I touched on the issue of @autoclosure. I continue to think that it's (to borrow Will's phrasing above) 'too clever', in that use of the attribute for the express purpose of discarding the closure is unprecedented in the standard library, and in that it

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

I'm fine with the proposal if it suits the core team / stdlib requirements for reasons previously stated. Some questions: Under SE-0136, the calls would be `MemoryLayout.size` and `MemoryLayout.size(ofValue: 2)`, with T inferred from the `size(ofValue:)` argument type. * Will it benefit the c

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

> On Aug 9, 2016, at 10:19 AM, Wallacy via swift-evolution > wrote: > > I believe the -O is already able to loop unroll correct > , but now C-Style loop is gone, and maybe will be more "difficult" to > compiler make this optimization, except of course using range literals. > > Em ter, 9 de

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

on Tue Aug 09 2016, Karl wrote: >> On 8 Aug 2016, at 04:18, Dave Abrahams wrote: >> >> >> 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”

Re: [swift-evolution] ABI of throwing

> On Aug 6, 2016, at 7:25 PM, Félix Cloutier via swift-evolution > wrote: > > Currently, Swift adds a hidden byref error parameter to propagate thrown > errors: > >> public func foo() throws { >> throw FooError.error >> } >> >> define void @_TF4test3fooFzT_T_(%swift.refcounted* nocaptur

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

I believe the -O is already able to loop unroll, but now C-Style loop is gone, and maybe will be more "difficult" to compiler make this optimization, except of course using range literals. Em ter, 9 de ago de 2016 às 13:10, Muse M via swift-evolution < swift-evolution@swift.org> escreveu: > -Oloo

Re: [swift-evolution] Secure Coding Guideline and SWIFT 3.0 release

This conversation would probably fit better on the swift-users mailing list. -- Keith Smiley On 08/09, Sunil Pandey via swift-evolution wrote: > Hi Team, > > Thanks for all of your effort on SWIFT :) > > Can anybody please help me with my queries mentioned below: > - Do we have secure coding guid

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

-Oloop Correction: it should be similar to GCC -funroll-loops On other option if we have 1,000,000's loops or array, it's bad for one core to handle 100% of the calculations and other cores are idle, the idea could be optimize loops to share/split workload across all available CPU cores. -Ofunctio

[swift-evolution] Secure Coding Guideline and SWIFT 3.0 release

Hi Team, Thanks for all of your effort on SWIFT :) Can anybody please help me with my queries mentioned below: - Do we have secure coding guidelines for SWIFT, please let me know where can I find the same - When can we expect formal *Swift 3.0 *release - Is there any risk If we already have start

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

My understanding is that -Ounchecked removes integer overflow checks and array bound checks. What type of optimizations would -Oloop and -Ofunction do? Félix > Le 7 août 2016 à 19:27:56, Muse M via swift-evolution > a écrit : > > I'm not sure if this is the right channel to discuss on optimi

Re: [swift-evolution] ABI of throwing

> “Zero cost” EH is also *extremely* expensive in the case where an error is > actually throw in normal use cases. This makes it completely inappropriate > for use in APIs where errors are expected in edge cases (e.g. file not found > errors). Anecdote: I work with a web service that gets seve

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

** What is your evaluation of the proposal?* This seems like obvious functionality. I know there are a couple places (especially when providing nice, Swifty interfaces for C functions) in the app I'm currently working on where I'd miss this functionality. The syntax is the most straightforward desi

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

On Tue, Aug 9, 2016 at 3:32 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 7, 2016, at 11:18 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > > * What is your evaluation of the proposal? > > I don't think that making

Re: [swift-evolution] [Proposal] Normalize Unicode Identifiers

The crunch from Swift 3 has now passed and I'm bringing up this proposal again. Should I go ahead and issue a pull request for this? Sincerely, João Pinheiro > On 26 Jul 2016, at 22:32, Chris Lattner wrote: > > >> On Jul 26, 2016, at 12:22 PM, João Pinheiro via swift-evolution >> mailto:swi

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

> On 8 Aug 2016, at 04:18, Dave Abrahams wrote: > > > 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 “o

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

> On Aug 7, 2016, at 11:18 AM, Dave Abrahams via swift-evolution > wrote: > > * What is your evaluation of the proposal? I don't think that making this public is so urgent that we need to approve it after the deadline. I suspect that a syntax for talking about the types associated with

Re: [swift-evolution] ABI of throwing

Sent from my iPhone On 9 Aug 2016, at 08:27, Brent Royal-Gordon via swift-evolution wrote: >> On Aug 7, 2016, at 9:36 PM, Chris Lattner via swift-evolution >> wrote: >> >>> However, as linked above, someone did for Microsoft platforms (for >>> Microsoft-platform-style errors) and found tha

Re: [swift-evolution] ABI of throwing

> On Aug 7, 2016, at 9:36 PM, Chris Lattner via swift-evolution > wrote: > >> However, as linked above, someone did for Microsoft platforms (for >> Microsoft-platform-style errors) and found that there is an impact. > > C++ and Swift are completely different languages in this respect, so the