Re: [swift-evolution] Binary framework distribution?

[Charlie Monroe via swift-evolution]

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, 晓敏 褚 via swift-evolution 
>  wrote:
> 
> 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 my project. This is a particularly bad experience in Xcode, as 
> CocoaPods and Carthage DOES allow Xcode to access the framework itself and 
> provide auto-completion and checking.
> No patent framework support. Open source is great, but there ARE developers 
> who want to share functionalities only, not the code. Apple releases iOS or 
> macOS frameworks, but most of them are not open sourced.
> A waste of time for huge frameworks. The current solution builds the 
> framework in every project. If the framework is something like scipy, a 
> significant longer build time is expected as compared to pre-built ones.
> 
> The existing UNIX dynamic libraries are also not good enough. They cause, 
> somehow, pollution to the system. The /usr/include /usr/lib system spread 
> files in different locations. And it is not easy to make an integrated 
> framework in an application.
> 
> And if we are able to directly create and distribute binary frameworks, all 
> of the problems are cleared. All of informations about the framework is 
> contained in itself, we could just download the frameworks for the particular 
> platform, and use them.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

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 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 
>>> > 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 
>>> time, Rust ended up dropping the segmented stacks because it significantly 
>>> complicated FFI without providing much, if any, benefit (and IIRC Go 
>>> followed suite and dropped segmented stacks somewhere around version 1.5), 
>>> and then a little while later Rust dropped green threads entirely. If you 
>>> can find them, there are lots of discussions of the pros and cons that were 
>>> documented during this process (on mailing lists, in IRC, possibly on 
>>> Discourse, there's probably at least one post about it in the Rust 
>>> subreddit, etc). But ultimately, it was determined that keeping this 
>>> ability significantly complicated the Rust runtime and it provided almost 
>>> no benefit. The OS is already really good at scheduling threads, and 
>>> there's no memory savings without segmented stacks (though the OS will map 
>>> virtual pages for the stack and only allocate the backing physical pages as 
>>> the memory is touched, so even if you have a 2MB stack, a new thread will 
>>> only actually allocate something like 8kb). And there are some pretty big 
>>> downsides to green threads, such as the fact that it significantly 
>>> complicates the runtime since all I/O everywhere has to be nonblocking and 
>>> it has to be transparent to the code, and FFI ends up as a major problem 
>>> (even without segmented stacks), because you have no idea if an FFI call 
>>> will block. Green threading libraries end up having to allocate extra OS 
>>> threads just to continue servicing the green threads when the existing 
>>> threads are potentially blocked in FFI.
>>> 
>>> So ultimately, green threads really only make sense when you control the 
>>> entire ecosystem, so you can ensure the whole stack is compatible with 
>>> green threads and won't ever issue blocking calls, and even there there's 
>>> not much benefit and there's a lot of complexity involved.
>> 
>> In addition to FFI, there's also no way for memory-mapped IO to be 
>> non-blocking (a page fault can only be handled by the kernel, after all).
>> 
>> -Joe
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI of throwing

[John McCall via swift-evolution]

> 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. You have Y*P calls that 
> succeed and *at most one* call that fails. That's because once you hit the 
> (1-P), you stop parsing. This heavily biases calls in favor of succeeding, 
> which is what I tried to illustrate with my anecdote.

This is true of JSON deserialization, where typically you wouldn't do something 
like prospectively deserialize a value one way and then try something else if 
that fails.  But it's not true of, say, a parser for a more ambiguous language, 
or for any number of other applications in which non-terminal failures are more 
common.

As Joe said, our intended ABI here is to get this down to a single 
branch-on-nonzero-register instruction immediately after the return, which is 
an overhead we're pretty comfortable with.

John.


> 
> I haven't attempted statistics in a while, but that looks like a geometric 
> distribution to me. That would give something like:
> 
> Y_1 * (1/P) + N_1 < Y_2 * (1/P) + N_2
> 
> in which Y completely dominates N, especially as P goes smaller.
> 
> Félix
> 
>> Le 9 août 2016 à 16:22:08, John McCall > > a écrit :
>> 
>>> 
>>> 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 
 (e.g. file not found errors).
>>> 
>>> Anecdote: I work with a web service that gets several million hits a day. 
>>> Management loves to use the percentage of succeeding web requests as a 
>>> measure of overall health. The problem with that metric is that when a web 
>>> request fails, clients fall in an unhealthy state and stop issuing requests 
>>> for a while. Therefore, one failing request prevents maybe twenty more that 
>>> would all have failed if the client hadn't bailed out, but these don't show 
>>> in statistics. This makes us look much better than we actually are.
>>> 
>>> If I had any amount of experience with DTrace, I'd write a script that logs 
>>> syscall errors to try and see how the programs that I use react to 
>>> failures. I'm almost certain that when one thing stops working, most 
>>> programs backs out of a much bigger process and don't retry right away. 
>>> When a program fails to open a file, it's also failing to read/write to it, 
>>> or whatever else people normally do after they open files. These things are 
>>> also expensive, and they're rarely the type of things that you need to (or 
>>> even just can) retry in a tight loop. My perception is that the immediate 
>>> cost of failing, even with expensive throwing, is generally dwarfed by the 
>>> immediate cost of succeeding, so we're not necessarily losing out on much.
>>> 
>>> And if that isn't the case, there are alternatives to throwing that people 
>>> are already embracing, to the point where error handling practices seem 
>>> fractured.
>>> 
> I don't really know what to expect in terms of discussion, especially 
> since it may boil down to "we're experts in this fields and you're just 
> peasants”
 
 I’m not sure why you think the Swift team would say something that 
 derogatory.  I hope there is no specific action that has led to this 
 belief. If there is, then please let me know.
>>> 
>>> Of course not. All of you have been very nice and patient with us peasants, 
>>> at least as far as "us" includes me. :) This was meant as a light-hearted 
>>> reflection on discussing intimate parts of the language, where my best 
>>> perspective is probably well-understood desktop/server development, whereas 
>>> the core team has to see that but also needs a high focus on other things 
>>> that don't even cross my mind (or at least, that's the heroic picture I 
>>> have of you guys).
>>> 
>>> For instance, my "expensive" stops at "takes a while". Your "expensive" 
>>> might mean "takes a while and drains the very finite energy reserves that 
>>> we have on this tiny device" or something still more expansive. These 
>>> differences are not always immediately obvious.
>>> 
> 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 
 analysis doesn’t translate over.
>>> 
>>> The analysis was (probably?) done over C++ and HRESULTs but with the 
>>> intention of applying it to another language (Midori), and it most likely 

[swift-evolution] Binary framework distribution?

[晓敏 褚 via swift-evolution]

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 
my project. This is a particularly bad experience in Xcode, as CocoaPods and 
Carthage DOES allow Xcode to access the framework itself and provide 
auto-completion and checking.
No patent framework support. Open source is great, but there ARE developers who 
want to share functionalities only, not the code. Apple releases iOS or macOS 
frameworks, but most of them are not open sourced.
A waste of time for huge frameworks. The current solution builds the framework 
in every project. If the framework is something like scipy, a significant 
longer build time is expected as compared to pre-built ones.

The existing UNIX dynamic libraries are also not good enough. They cause, 
somehow, pollution to the system. The /usr/include /usr/lib system spread files 
in different locations. And it is not easy to make an integrated framework in 
an application.

And if we are able to directly create and distribute binary frameworks, all of 
the problems are cleared. All of informations about the framework is contained 
in itself, we could just download the frameworks for the particular platform, 
and use them.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI of throwing

[Félix Cloutier via swift-evolution]

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 fails. That's because once you hit the (1-P), you stop 
parsing. This heavily biases calls in favor of succeeding, which is what I 
tried to illustrate with my anecdote.

I haven't attempted statistics in a while, but that looks like a geometric 
distribution to me. That would give something like:

Y_1 * (1/P) + N_1 < Y_2 * (1/P) + N_2

in which Y completely dominates N, especially as P goes smaller.

Félix

> Le 9 août 2016 à 16:22:08, John McCall  a écrit :
> 
>> 
>> 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 (e.g. file not 
>>> found errors).
>> 
>> Anecdote: I work with a web service that gets several million hits a day. 
>> Management loves to use the percentage of succeeding web requests as a 
>> measure of overall health. The problem with that metric is that when a web 
>> request fails, clients fall in an unhealthy state and stop issuing requests 
>> for a while. Therefore, one failing request prevents maybe twenty more that 
>> would all have failed if the client hadn't bailed out, but these don't show 
>> in statistics. This makes us look much better than we actually are.
>> 
>> If I had any amount of experience with DTrace, I'd write a script that logs 
>> syscall errors to try and see how the programs that I use react to failures. 
>> I'm almost certain that when one thing stops working, most programs backs 
>> out of a much bigger process and don't retry right away. When a program 
>> fails to open a file, it's also failing to read/write to it, or whatever 
>> else people normally do after they open files. These things are also 
>> expensive, and they're rarely the type of things that you need to (or even 
>> just can) retry in a tight loop. My perception is that the immediate cost of 
>> failing, even with expensive throwing, is generally dwarfed by the immediate 
>> cost of succeeding, so we're not necessarily losing out on much.
>> 
>> And if that isn't the case, there are alternatives to throwing that people 
>> are already embracing, to the point where error handling practices seem 
>> fractured.
>> 
 I don't really know what to expect in terms of discussion, especially 
 since it may boil down to "we're experts in this fields and you're just 
 peasants”
>>> 
>>> I’m not sure why you think the Swift team would say something that 
>>> derogatory.  I hope there is no specific action that has led to this 
>>> belief. If there is, then please let me know.
>> 
>> Of course not. All of you have been very nice and patient with us peasants, 
>> at least as far as "us" includes me. :) This was meant as a light-hearted 
>> reflection on discussing intimate parts of the language, where my best 
>> perspective is probably well-understood desktop/server development, whereas 
>> the core team has to see that but also needs a high focus on other things 
>> that don't even cross my mind (or at least, that's the heroic picture I have 
>> of you guys).
>> 
>> For instance, my "expensive" stops at "takes a while". Your "expensive" 
>> might mean "takes a while and drains the very finite energy reserves that we 
>> have on this tiny device" or something still more expansive. These 
>> differences are not always immediately obvious.
>> 
 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 
>>> analysis doesn’t translate over.
>> 
>> The analysis was (probably?) done over C++ and HRESULTs but with the 
>> intention of applying it to another language (Midori), and it most likely 
>> validated the approach of other languages (essentially everything 
>> .NET-based). Several findings of the Midori team are being exported to 
>> Microsoft's new APIs, notably the async everywhere and exceptions everywhere 
>> paradigms, and these APIs are callable from both so-called managed programs 
>> (GCed) and unmanaged programs (ref-counted).
>> 
>> Swift operations don't tend to throw very much, which is a net positive, but 
>> it seems to me that comparing the impact of Swift throws with another 
>> language's throws is relatively fair. C# isn't shy of 
>> FileNotFoundExceptions, for instance.
> 
> I think you may be missing Chris's point here.
> 
> Exception ABIs trade off between two different cases: when the 

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

[Charles Srstka via swift-evolution]

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 abruptly 
went “Oh God, not that guy again” and decided to stop responding. ;-)

Will probably file a few more as I think of them, when I can get into the 
server again.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Ilseman via swift-evolution]

> 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 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 many of the standard
>> library's design decisions for years to come.  What we only realized
>> very recently is that, although Swift 3.0 is *not* shipping with a
>> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
>> code creates similar implications when it comes to certain protocols,
>> today.  Especially where these protocols show up in refinement
>> hierarchies, we can't keep Swift 3 code working in the future without
>> carrying them forward into future libraries.
>> 
>> The proposed changes are as follows:
>> 
>> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>> This component is really only useful for playgrounds, and doesn't
>> belong in the standard library.
>> 
>> * Deprecate the Indexable protocols with a message indicating that they
>> will be gone in Swift 4.  These protocols are implementation details
>> of the standard library designed to work around language limitations
>> that we expect to be gone in Swift 4.  There's no reason for anyone to
>> ever touch these; users should always use a corresponding Collection
>> protocol (e.g. instead of MutableIndexable, use MutableCollection).
>> 
>> * Deprecate the ExpressibleByStringInterpolation protocol with a
>> message indicating that its design is expected to change.  We know
>> this protocol to be mis-designed
>> (https://bugs.swift.org/browse/SR-1260) and limited
>> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>> for Swift 3.  If we knew what the new design should look like, we
>> might be able to calculate that the current API is supportable in a
>> forward-compatible way (as we do for Comparable).  Unfortunately, we
>> do not.
>> 
>> * Rename Streamable to TextOutputStreamable and add a deprecated
>> Streamable typealias for it.  Now that OutputStream been renamed to
>> TextOutputStream, we should also move Streamable out of the way.
>> 
>> Deprecation is being proposed instead of underscoring or renaming
>> because it allows existing code to keep working (with warnings).  At
>> this late stage, it would be bad to actually break anything.
> 
> Is the team taking suggestions on APIs to be deprecated, renamed and/or 
> modified? I’ve been noticing quite a few translated ObjC APIs that don’t 
> quite seem to fit the Swift paradigm lately.
> 

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!

> Charles
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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/proposals/0137-avoiding-lock-in.md

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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:
>> 
>> We've always known that when Swift reached ABI stability (now slated for
>> Swift 4), we would be committed to supporting many of the standard
>> library's design decisions for years to come.  What we only realized
>> very recently is that, although Swift 3.0 is *not* shipping with a
>> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
>> code creates similar implications when it comes to certain protocols,
>> today.  Especially where these protocols show up in refinement
>> hierarchies, we can't keep Swift 3 code working in the future without
>> carrying them forward into future libraries.
>> 
>> The proposed changes are as follows:
>> 
>> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>>  This component is really only useful for playgrounds, and doesn't
>>  belong in the standard library.
>
> I didn't think it was possible to `import PlaygroundSupport` unless the 
> current file is within a playground. If so, how can corelibs-foundation 
> or third-party modules add `CustomPlaygroundQuickLookable`
> conformance?

Ahhh... yeah, I didn't realize that, and we don't have time to change
that restriction for Swift 3.  It's not a problem for
corelibs-foundation but it would be for 3rd-party libraries.  

OK, Dmitri and I just figured out how we can change the home of these
types for Swift 4 without breaking Swift 3 code (mirrors to the rescue!)
So I'm going to withdraw this part of the proposal.

>> * Deprecate the Indexable protocols with a message indicating that they
>>  will be gone in Swift 4.  These protocols are implementation details
>>  of the standard library designed to work around language limitations
>>  that we expect to be gone in Swift 4.  There's no reason for anyone to
>>  ever touch these; users should always use a corresponding Collection
>>  protocol (e.g. instead of MutableIndexable, use MutableCollection).
>> 
>> * Deprecate the ExpressibleByStringInterpolation protocol with a
>>  message indicating that its design is expected to change.  We know
>>  this protocol to be mis-designed
>>  (https://bugs.swift.org/browse/SR-1260) and limited
>>  (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>>  for Swift 3.  If we knew what the new design should look like, we
>>  might be able to calculate that the current API is supportable in a
>>  forward-compatible way (as we do for Comparable).  Unfortunately, we
>>  do not.
>> 
>> * Rename Streamable to TextOutputStreamable and add a deprecated
>>  Streamable typealias for it.  Now that OutputStream been renamed to
>>  TextOutputStream, we should also move Streamable out of the way.
>> 
>> Deprecation is being proposed instead of underscoring or renaming
>> because it allows existing code to keep working (with warnings).  At
>> this late stage, it would be bad to actually break anything.
>
> If the SE-0104 (protocol-oriented integers) proposal has been deferred, 
> should any protocols (e.g. SignedNumber) be deprecated?
>
> -- Ben
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI of throwing

[John McCall via swift-evolution]

> 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 (e.g. file not found 
>> errors).
> 
> Anecdote: I work with a web service that gets several million hits a day. 
> Management loves to use the percentage of succeeding web requests as a 
> measure of overall health. The problem with that metric is that when a web 
> request fails, clients fall in an unhealthy state and stop issuing requests 
> for a while. Therefore, one failing request prevents maybe twenty more that 
> would all have failed if the client hadn't bailed out, but these don't show 
> in statistics. This makes us look much better than we actually are.
> 
> If I had any amount of experience with DTrace, I'd write a script that logs 
> syscall errors to try and see how the programs that I use react to failures. 
> I'm almost certain that when one thing stops working, most programs backs out 
> of a much bigger process and don't retry right away. When a program fails to 
> open a file, it's also failing to read/write to it, or whatever else people 
> normally do after they open files. These things are also expensive, and 
> they're rarely the type of things that you need to (or even just can) retry 
> in a tight loop. My perception is that the immediate cost of failing, even 
> with expensive throwing, is generally dwarfed by the immediate cost of 
> succeeding, so we're not necessarily losing out on much.
> 
> And if that isn't the case, there are alternatives to throwing that people 
> are already embracing, to the point where error handling practices seem 
> fractured.
> 
>>> I don't really know what to expect in terms of discussion, especially since 
>>> it may boil down to "we're experts in this fields and you're just peasants”
>> 
>> I’m not sure why you think the Swift team would say something that 
>> derogatory.  I hope there is no specific action that has led to this belief. 
>> If there is, then please let me know.
> 
> Of course not. All of you have been very nice and patient with us peasants, 
> at least as far as "us" includes me. :) This was meant as a light-hearted 
> reflection on discussing intimate parts of the language, where my best 
> perspective is probably well-understood desktop/server development, whereas 
> the core team has to see that but also needs a high focus on other things 
> that don't even cross my mind (or at least, that's the heroic picture I have 
> of you guys).
> 
> For instance, my "expensive" stops at "takes a while". Your "expensive" might 
> mean "takes a while and drains the very finite energy reserves that we have 
> on this tiny device" or something still more expansive. These differences are 
> not always immediately obvious.
> 
>>> 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 
>> analysis doesn’t translate over.
> 
> The analysis was (probably?) done over C++ and HRESULTs but with the 
> intention of applying it to another language (Midori), and it most likely 
> validated the approach of other languages (essentially everything 
> .NET-based). Several findings of the Midori team are being exported to 
> Microsoft's new APIs, notably the async everywhere and exceptions everywhere 
> paradigms, and these APIs are callable from both so-called managed programs 
> (GCed) and unmanaged programs (ref-counted).
> 
> Swift operations don't tend to throw very much, which is a net positive, but 
> it seems to me that comparing the impact of Swift throws with another 
> language's throws is relatively fair. C# isn't shy of FileNotFoundExceptions, 
> for instance.

I think you may be missing Chris's point here.

Exception ABIs trade off between two different cases: when the callee throws 
and when it doesn't.  (There are multiple dimensions of trade-off here, but 
let's just talk about cycle-count performance.)  Suppose that a compiler can 
implement a call to have cost C if it just "un-implements" exceptions, the way 
that a C++ compiler does when they're disabled.  If we hand-wave a bit, we can 
pretend that all the costs are local and just say that any particular ABI will 
add cost N to calls that don't throw and cost Y to calls that do.  Therefore, 
if calls throw with probability P, ABI 1 will be faster than ABI 2 if:
   Y_1 * P +  N_1 * (1 - P) < Y_2 * P +  N_2 * (1 - P)

So what is P?  Well, there's a really important difference between programming 
languages.

In C++ or C#, you have to compute P as a proportion of every call made by the 
program.  (Technically, C++ has a way to annotate that a function doesn't 
throw, and it's possible under very specific 

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

[Paulo Faria via swift-evolution]

+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 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 many of the standard
>>> library's design decisions for years to come.  What we only realized
>>> very recently is that, although Swift 3.0 is *not* shipping with a
>>> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
>>> code creates similar implications when it comes to certain protocols,
>>> today.  Especially where these protocols show up in refinement
>>> hierarchies, we can't keep Swift 3 code working in the future without
>>> carrying them forward into future libraries.
>>> 
>>> The proposed changes are as follows:
>>> 
>>> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>>> This component is really only useful for playgrounds, and doesn't
>>> belong in the standard library.
>>> 
>>> * Deprecate the Indexable protocols with a message indicating that they
>>> will be gone in Swift 4.  These protocols are implementation details
>>> of the standard library designed to work around language limitations
>>> that we expect to be gone in Swift 4.  There's no reason for anyone to
>>> ever touch these; users should always use a corresponding Collection
>>> protocol (e.g. instead of MutableIndexable, use MutableCollection).
>>> 
>>> * Deprecate the ExpressibleByStringInterpolation protocol with a
>>> message indicating that its design is expected to change.  We know
>>> this protocol to be mis-designed
>>> (https://bugs.swift.org/browse/SR-1260) and limited
>>> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>>> for Swift 3.  If we knew what the new design should look like, we
>>> might be able to calculate that the current API is supportable in a
>>> forward-compatible way (as we do for Comparable).  Unfortunately, we
>>> do not.
>>> 
>>> * Rename Streamable to TextOutputStreamable and add a deprecated
>>> Streamable typealias for it.  Now that OutputStream been renamed to
>>> TextOutputStream, we should also move Streamable out of the way.
>>> 
>>> Deprecation is being proposed instead of underscoring or renaming
>>> because it allows existing code to keep working (with warnings).  At
>>> this late stage, it would be bad to actually break anything.
>>> 
>>> -- 
>>> -Dave
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> Does this include the ContiguousArray deprecation? 
> 
> Definitely not.
> 
>> I’m still seeing performance issues with regular Array (will update
>> bug soon).
>> 
>> I don’t mind if it gets deprecated, so long as it isn’t removed before we 
>> sort those issues out.
>> 
>> Otherwise +1
>> 
>> Karl
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> -- 
> -Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 
>> > 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 ago de 2016 às 13:10, Muse M via swift-evolution 
>> > escreveu:
>> -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. 
>> 
>> -Ofunction
>> Is a dummy example for other example.
>> 
>> On Tue, Aug 9, 2016 at 11:21 PM, Félix Cloutier > > wrote:
>> 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 optimization switch
>>> 
>>> We are aware the 3 options:
>>> -O
>>> -Ofast
>>> -Ounchecked
> 
> We have -O and -Ounchecked.
> -Ofast is obsolete.
> 
> 
>>> 
>>> 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 loop or maths optimization or allow developers to 
>>> fine-tuning in various area, we could add more options to compiler.
>>> 
>>> -OLoop (Optimize loop with safety)
>>> -OFunc (Optimize function calls)
>>> and so on.
>>> 
> 
> I think you are asking for a way to fine tune optimizations for a specific 
> purpose.
> Fine-tuning optimizations is mostly intended for small parts of the code, 
> like a function or even a loop.
> But optimization switches apply to the whole module (assuming 
> whole-module-optimization). So an optimization switch is not really a good 
> tool for fine tuning.
> 
> In general I believe there must be a good justification for adding an 
> optimization switch/mode. E.g. it must be well understandable what it does 
> and what's the difference to existing optimization modes.

Right.  Global optimization switches are generally a bad move; it's almost 
always better to have something more locally-scoped, like perhaps an 
OpenMP-like annotation on a loop encouraging it to be unrolled or parallelized.

John.

> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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 as follows:
>> 
>> We've always known that when Swift reached ABI stability (now slated for
>> Swift 4), we would be committed to supporting many of the standard
>> library's design decisions for years to come.  What we only realized
>> very recently is that, although Swift 3.0 is *not* shipping with a
>> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
>> code creates similar implications when it comes to certain protocols,
>> today.  Especially where these protocols show up in refinement
>> hierarchies, we can't keep Swift 3 code working in the future without
>> carrying them forward into future libraries.
>> 
>> The proposed changes are as follows:
>> 
>> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>>  This component is really only useful for playgrounds, and doesn't
>>  belong in the standard library.
>> 
>> * Deprecate the Indexable protocols with a message indicating that they
>>  will be gone in Swift 4.  These protocols are implementation details
>>  of the standard library designed to work around language limitations
>>  that we expect to be gone in Swift 4.  There's no reason for anyone to
>>  ever touch these; users should always use a corresponding Collection
>>  protocol (e.g. instead of MutableIndexable, use MutableCollection).
>> 
>> * Deprecate the ExpressibleByStringInterpolation protocol with a
>>  message indicating that its design is expected to change.  We know
>>  this protocol to be mis-designed
>>  (https://bugs.swift.org/browse/SR-1260) and limited
>>  (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>>  for Swift 3.  If we knew what the new design should look like, we
>>  might be able to calculate that the current API is supportable in a
>>  forward-compatible way (as we do for Comparable).  Unfortunately, we
>>  do not.
>> 
>> * Rename Streamable to TextOutputStreamable and add a deprecated
>>  Streamable typealias for it.  Now that OutputStream been renamed to
>>  TextOutputStream, we should also move Streamable out of the way.
>> 
>> Deprecation is being proposed instead of underscoring or renaming
>> because it allows existing code to keep working (with warnings).  At
>> this late stage, it would be bad to actually break anything.
>> 
>> -- 
>> -Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> Does this include the ContiguousArray deprecation? 

Definitely not.

> I’m still seeing performance issues with regular Array (will update
> bug soon).
>
> I don’t mind if it gets deprecated, so long as it isn’t removed before we 
> sort those issues out.
>
> Otherwise +1
>
> Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl via swift-evolution]

> 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 Swift reached ABI stability (now slated for
> Swift 4), we would be committed to supporting many of the standard
> library's design decisions for years to come.  What we only realized
> very recently is that, although Swift 3.0 is *not* shipping with a
> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> code creates similar implications when it comes to certain protocols,
> today.  Especially where these protocols show up in refinement
> hierarchies, we can't keep Swift 3 code working in the future without
> carrying them forward into future libraries.
> 
> The proposed changes are as follows:
> 
> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>  This component is really only useful for playgrounds, and doesn't
>  belong in the standard library.
> 
> * Deprecate the Indexable protocols with a message indicating that they
>  will be gone in Swift 4.  These protocols are implementation details
>  of the standard library designed to work around language limitations
>  that we expect to be gone in Swift 4.  There's no reason for anyone to
>  ever touch these; users should always use a corresponding Collection
>  protocol (e.g. instead of MutableIndexable, use MutableCollection).
> 
> * Deprecate the ExpressibleByStringInterpolation protocol with a
>  message indicating that its design is expected to change.  We know
>  this protocol to be mis-designed
>  (https://bugs.swift.org/browse/SR-1260) and limited
>  (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>  for Swift 3.  If we knew what the new design should look like, we
>  might be able to calculate that the current API is supportable in a
>  forward-compatible way (as we do for Comparable).  Unfortunately, we
>  do not.
> 
> * Rename Streamable to TextOutputStreamable and add a deprecated
>  Streamable typealias for it.  Now that OutputStream been renamed to
>  TextOutputStream, we should also move Streamable out of the way.
> 
> Deprecation is being proposed instead of underscoring or renaming
> because it allows existing code to keep working (with warnings).  At
> this late stage, it would be bad to actually break anything.
> 
> -- 
> -Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


Does this include the ContiguousArray deprecation? I’m still seeing performance 
issues with regular Array (will update bug soon).

I don’t mind if it gets deprecated, so long as it isn’t removed before we sort 
those issues out.

Otherwise +1

Karl

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

> 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 (now slated for
> Swift 4), we would be committed to supporting many of the standard
> library's design decisions for years to come.  What we only realized
> very recently is that, although Swift 3.0 is *not* shipping with a
> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> code creates similar implications when it comes to certain protocols,
> today.  Especially where these protocols show up in refinement
> hierarchies, we can't keep Swift 3 code working in the future without
> carrying them forward into future libraries.
> 
> The proposed changes are as follows:
> 
> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>  This component is really only useful for playgrounds, and doesn't
>  belong in the standard library.

I didn't think it was possible to `import PlaygroundSupport` unless the 
current file is within a playground. If so, how can corelibs-foundation 
or third-party modules add `CustomPlaygroundQuickLookable` conformance?

> * Deprecate the Indexable protocols with a message indicating that they
>  will be gone in Swift 4.  These protocols are implementation details
>  of the standard library designed to work around language limitations
>  that we expect to be gone in Swift 4.  There's no reason for anyone to
>  ever touch these; users should always use a corresponding Collection
>  protocol (e.g. instead of MutableIndexable, use MutableCollection).
> 
> * Deprecate the ExpressibleByStringInterpolation protocol with a
>  message indicating that its design is expected to change.  We know
>  this protocol to be mis-designed
>  (https://bugs.swift.org/browse/SR-1260) and limited
>  (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>  for Swift 3.  If we knew what the new design should look like, we
>  might be able to calculate that the current API is supportable in a
>  forward-compatible way (as we do for Comparable).  Unfortunately, we
>  do not.
> 
> * Rename Streamable to TextOutputStreamable and add a deprecated
>  Streamable typealias for it.  Now that OutputStream been renamed to
>  TextOutputStream, we should also move Streamable out of the way.
> 
> Deprecation is being proposed instead of underscoring or renaming
> because it allows existing code to keep working (with warnings).  At
> this late stage, it would be bad to actually break anything.

If the SE-0104 (protocol-oriented integers) proposal has been deferred, 
should any protocols (e.g. SignedNumber) be deprecated?

-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

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 
>>  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 time, Rust 
>> ended up dropping the segmented stacks because it significantly complicated 
>> FFI without providing much, if any, benefit (and IIRC Go followed suite and 
>> dropped segmented stacks somewhere around version 1.5), and then a little 
>> while later Rust dropped green threads entirely. If you can find them, there 
>> are lots of discussions of the pros and cons that were documented during 
>> this process (on mailing lists, in IRC, possibly on Discourse, there's 
>> probably at least one post about it in the Rust subreddit, etc). But 
>> ultimately, it was determined that keeping this ability significantly 
>> complicated the Rust runtime and it provided almost no benefit. The OS is 
>> already really good at scheduling threads, and there's no memory savings 
>> without segmented stacks (though the OS will map virtual pages for the stack 
>> and only allocate the backing physical pages as the memory is touched, so 
>> even if you have a 2MB stack, a new thread will only actually allocate 
>> something like 8kb). And there are some pretty big downsides to green 
>> threads, such as the fact that it significantly complicates the runtime 
>> since all I/O everywhere has to be nonblocking and it has to be transparent 
>> to the code, and FFI ends up as a major problem (even without segmented 
>> stacks), because you have no idea if an FFI call will block. Green threading 
>> libraries end up having to allocate extra OS threads just to continue 
>> servicing the green threads when the existing threads are potentially 
>> blocked in FFI.
>> 
>> So ultimately, green threads really only make sense when you control the 
>> entire ecosystem, so you can ensure the whole stack is compatible with green 
>> threads and won't ever issue blocking calls, and even there there's not much 
>> benefit and there's a lot of complexity involved.
> 
> In addition to FFI, there's also no way for memory-mapped IO to be 
> non-blocking (a page fault can only be handled by the kernel, after all).
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

+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've always known that when Swift reached ABI stability (now slated for
> Swift 4), we would be committed to supporting many of the standard
> library's design decisions for years to come.  What we only realized
> very recently is that, although Swift 3.0 is *not* shipping with a
> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> code creates similar implications when it comes to certain protocols,
> today.  Especially where these protocols show up in refinement
> hierarchies, we can't keep Swift 3 code working in the future without
> carrying them forward into future libraries.
> 
> The proposed changes are as follows:
> 
> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>  This component is really only useful for playgrounds, and doesn't
>  belong in the standard library.
> 
> * Deprecate the Indexable protocols with a message indicating that they
>  will be gone in Swift 4.  These protocols are implementation details
>  of the standard library designed to work around language limitations
>  that we expect to be gone in Swift 4.  There's no reason for anyone to
>  ever touch these; users should always use a corresponding Collection
>  protocol (e.g. instead of MutableIndexable, use MutableCollection).
> 
> * Deprecate the ExpressibleByStringInterpolation protocol with a
>  message indicating that its design is expected to change.  We know
>  this protocol to be mis-designed
>  (https://bugs.swift.org/browse/SR-1260) and limited
>  (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>  for Swift 3.  If we knew what the new design should look like, we
>  might be able to calculate that the current API is supportable in a
>  forward-compatible way (as we do for Comparable).  Unfortunately, we
>  do not.
> 
> * Rename Streamable to TextOutputStreamable and add a deprecated
>  Streamable typealias for it.  Now that OutputStream been renamed to
>  TextOutputStream, we should also move Streamable out of the way.
> 
> Deprecation is being proposed instead of underscoring or renaming
> because it allows existing code to keep working (with warnings).  At
> this late stage, it would be bad to actually break anything.
> 
> -- 
> -Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

> 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 time, Rust 
> ended up dropping the segmented stacks because it significantly complicated 
> FFI without providing much, if any, benefit (and IIRC Go followed suite and 
> dropped segmented stacks somewhere around version 1.5), and then a little 
> while later Rust dropped green threads entirely. If you can find them, there 
> are lots of discussions of the pros and cons that were documented during this 
> process (on mailing lists, in IRC, possibly on Discourse, there's probably at 
> least one post about it in the Rust subreddit, etc). But ultimately, it was 
> determined that keeping this ability significantly complicated the Rust 
> runtime and it provided almost no benefit. The OS is already really good at 
> scheduling threads, and there's no memory savings without segmented stacks 
> (though the OS will map virtual pages for the stack and only allocate the 
> backing physical pages as the memory is touched, so even if you have a 2MB 
> stack, a new thread will only actually allocate something like 8kb). And 
> there are some pretty big downsides to green threads, such as the fact that 
> it significantly complicates the runtime since all I/O everywhere has to be 
> nonblocking and it has to be transparent to the code, and FFI ends up as a 
> major problem (even without segmented stacks), because you have no idea if an 
> FFI call will block. Green threading libraries end up having to allocate 
> extra OS threads just to continue servicing the green threads when the 
> existing threads are potentially blocked in FFI.
> 
> So ultimately, green threads really only make sense when you control the 
> entire ecosystem, so you can ensure the whole stack is compatible with green 
> threads and won't ever issue blocking calls, and even there there's not much 
> benefit and there's a lot of complexity involved.

In addition to FFI, there's also no way for memory-mapped IO to be non-blocking 
(a page fault can only be handled by the kernel, after all).

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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 space is wide open.

> Perhaps it would work to separate these two requirements, allowing the
> segments to construct intermediate types, and only requiring the type
> adopting ExpressibleByStringInterpolation to implement
> init(stringInterpolation:).
>
> This would be nice because it would be much easier for types which aren't
> enums to conform to ExpressibleByStringInterpolation. In my auto layout
> example (https://gist.github.com/jtbandes/9c1c25ee4996d2554375), the
> ConstraintCollection type is only an enum because it has to provide all the
> initializers, but it's strange that the cases are accessible publicly;

I'm not sure whether what you're describing is just a limitation in our
access control (a public type conforming to a protocol must expose all
of that protocol's requirements as public members).  If so, maybe we
should fix *that*, rather than morphing designs to work around it.

That said, I don't really have time to think about the design of
ExpressibleByStringInterpolation in detail at the moment, as we're right
up against the Swift 3 ship date (sorry!)  If you'd bring it up in a few
months I'm sure I'll have a lot more bandwidth for it.

Thanks,

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI of throwing

[David Rönnqvist via swift-evolution]

>> “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 several million hits a day. 
> Management loves to use the percentage of succeeding web requests as a 
> measure of overall health. The problem with that metric is that when a web 
> request fails, clients fall in an unhealthy state and stop issuing requests 
> for a while. Therefore, one failing request prevents maybe twenty more that 
> would all have failed if the client hadn't bailed out, but these don't show 
> in statistics. This makes us look much better than we actually are.
> 
> If I had any amount of experience with DTrace, I'd write a script that logs 
> syscall errors to try and see how the programs that I use react to failures. 
> I'm almost certain that when one thing stops working, most programs backs out 
> of a much bigger process and don't retry right away. When a program fails to 
> open a file, it's also failing to read/write to it, or whatever else people 
> normally do after they open files. These things are also expensive, and 
> they're rarely the type of things that you need to (or even just can) retry 
> in a tight loop. My perception is that the immediate cost of failing, even 
> with expensive throwing, is generally dwarfed by the immediate cost of 
> succeeding, so we're not necessarily losing out on much.
> 
> And if that isn't the case, there are alternatives to throwing that people 
> are already embracing, to the point where error handling practices seem 
> fractured.
> 
>>> I don't really know what to expect in terms of discussion, especially since 
>>> it may boil down to "we're experts in this fields and you're just peasants”
>> 
>> I’m not sure why you think the Swift team would say something that 
>> derogatory.  I hope there is no specific action that has led to this belief. 
>> If there is, then please let me know.
> 
> Of course not. All of you have been very nice and patient with us peasants, 
> at least as far as "us" includes me. :)

Sorry for derailing the actual error handling discussion. I just wanted to say 
this:

Don't think less of yourself or devalue your experience and opinions because 
you don't write a compiler or a programming language for a living. I don't do 
either of those two things either. 

A diverse set of perspectives and experiences will only benefit the design of 
the language and its libraries. 

As an example, later when it's time to discuss concurrency, different contexts 
and perspectives will have different priorities. For some it will be about 
responsive UIs, for others it will be parallelism, fault tolerance, distributed 
programming, and more.

If your perspective isn't represented in those discussions then that could mean 
that valuable information isn't taken into the appropriate consideration. 

Even if certain topics can get heated at times, someone's _idea_ or point of 
view can be discussed, reasoned about, and be turned down without it in anyway 
being intended towards that person. 

So just like me, try not to get discouraged by all the other smart people on 
this mailing list that have other experience and know so much about other 
things than you and I do. :)

That said, back to the discussion about error handling ;)

> This was meant as a light-hearted reflection on discussing intimate parts of 
> the language, where my best perspective is probably well-understood 
> desktop/server development, whereas the core team has to see that but also 
> needs a high focus on other things that don't even cross my mind (or at 
> least, that's the heroic picture I have of you guys).
> 
> For instance, my "expensive" stops at "takes a while". Your "expensive" might 
> mean "takes a while and drains the very finite energy reserves that we have 
> on this tiny device" or something still more expansive. These differences are 
> not always immediately obvious.
> 
>>> 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 
>> analysis doesn’t translate over.
> 
> The analysis was (probably?) done over C++ and HRESULTs but with the 
> intention of applying it to another language (Midori), and it most likely 
> validated the approach of other languages (essentially everything 
> .NET-based). Several findings of the Midori team are being exported to 
> Microsoft's new APIs, notably the async everywhere and exceptions everywhere 
> paradigms, and these APIs are callable from both so-called managed programs 
> (GCed) and unmanaged programs (ref-counted).
> 
> Swift operations don't tend to throw very much, which is a net positive, but 
> it seems to me that comparing the impact of 

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

[Kevin Ballard via swift-evolution]

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 complicated FFI without 
providing much, if any, benefit (and IIRC Go followed suite and dropped 
segmented stacks somewhere around version 1.5), and then a little while later 
Rust dropped green threads entirely. If you can find them, there are lots of 
discussions of the pros and cons that were documented during this process (on 
mailing lists, in IRC, possibly on Discourse, there's probably at least one 
post about it in the Rust subreddit, etc). But ultimately, it was determined 
that keeping this ability significantly complicated the Rust runtime and it 
provided almost no benefit. The OS is already really good at scheduling 
threads, and there's no memory savings without segmented stacks (though the OS 
will map virtual pages for the stack and only allocate the backing physical 
pages as the memory is touched, so even if you have a 2MB stack, a new thread 
will only actually allocate something like 8kb). And there are some pretty big 
downsides to green threads, such as the fact that it significantly complicates 
the runtime since all I/O everywhere has to be nonblocking and it has to be 
transparent to the code, and FFI ends up as a major problem (even without 
segmented stacks), because you have no idea if an FFI call will block. Green 
threading libraries end up having to allocate extra OS threads just to continue 
servicing the green threads when the existing threads are potentially blocked 
in FFI.

So ultimately, green threads really only make sense when you control the entire 
ecosystem, so you can ensure the whole stack is compatible with green threads 
and won't ever issue blocking calls, and even there there's not much benefit 
and there's a lot of complexity involved.

-Kevin Ballard

On Tue, Aug 9, 2016, at 12:04 PM, Dan Stenmark via swift-evolution wrote:
> 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 language's use of 
> Green Threads and how the runtime handles the heavy lifting of multiplexing 
> and scheduling them.  What are some of the strengths and weaknesses the Swift 
> team sees to Go's approach?
> 
> Dan
> 
> (DISCLAIMER: I'm posting this for academic reasons, not as a pitch.  While 
> the Swift team's responses may inform opinions on the matter, I do not want 
> this to turn into a 'this is how I think Swift should do concurrency' debate. 
>  That discussion will come when it comes.)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> 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 when Swift reached ABI stability (now slated for
> Swift 4), we would be committed to supporting many of the standard
> library's design decisions for years to come.  What we only realized
> very recently is that, although Swift 3.0 is *not* shipping with a
> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> code creates similar implications when it comes to certain protocols,
> today.  Especially where these protocols show up in refinement
> hierarchies, we can't keep Swift 3 code working in the future without
> carrying them forward into future libraries.
> 
> The proposed changes are as follows:
> 
> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>  This component is really only useful for playgrounds, and doesn't
>  belong in the standard library.
> 
> * Deprecate the Indexable protocols with a message indicating that they
>  will be gone in Swift 4.  These protocols are implementation details
>  of the standard library designed to work around language limitations
>  that we expect to be gone in Swift 4.  There's no reason for anyone to
>  ever touch these; users should always use a corresponding Collection
>  protocol (e.g. instead of MutableIndexable, use MutableCollection).
> 
> * Deprecate the ExpressibleByStringInterpolation protocol with a
>  message indicating that its design is expected to change.  We know
>  this protocol to be mis-designed
>  (https://bugs.swift.org/browse/SR-1260) and limited
>  (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>  for Swift 3.  If we knew what the new design should look like, we
>  might be able to calculate that the current API is supportable in a
>  forward-compatible way (as we do for Comparable).  Unfortunately, we
>  do not.
> 
> * Rename Streamable to TextOutputStreamable and add a deprecated
>  Streamable typealias for it.  Now that OutputStream been renamed to
>  TextOutputStream, we should also move Streamable out of the way.
> 
> Deprecation is being proposed instead of underscoring or renaming
> because it allows existing code to keep working (with warnings).  At
> this late stage, it would be bad to actually break anything.

Is the team taking suggestions on APIs to be deprecated, renamed and/or 
modified? I’ve been noticing quite a few translated ObjC APIs that don’t quite 
seem to fit the Swift paradigm lately.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 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 um 14:41 schrieb Björn Forster via swift-evolution <
> swift-evolution@swift.org>:
> >
> > Hello Swift community,
> > to make use of Swift more appealing and useful for science, engineering
> and finance and everything else involving actually calculating things, I
> think it would be a big step forward if Swift would ship with its own
> math/numerics library.
> >
> > Wouldn't it be great if Swift would offer functionality similar to Numpy
> in its native math lib? It think it would be great to have a "standard"
> annotation for vector arithmetic that the Swift community has agreed on and
> that scientific packages can build on.
> >
> > Which functionality should be covered by a Swift's math lib and where
> should be drawn the line?
> >
> > Any thoughts?
> >
> > (If it is not the right time now to talk this topic, as it is not
> mentioned in the goals for Swift 4 by Chris, I apologize for bringing this
> up now. But I think then this should be discussed later at some point not
> in the infinite future)
> >
> > Björn
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

+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
> 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 many of the standard
> library's design decisions for years to come.  What we only realized
> very recently is that, although Swift 3.0 is *not* shipping with a
> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> code creates similar implications when it comes to certain protocols,
> today.  Especially where these protocols show up in refinement
> hierarchies, we can't keep Swift 3 code working in the future without
> carrying them forward into future libraries.
>
> The proposed changes are as follows:
>
> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>   This component is really only useful for playgrounds, and doesn't
>   belong in the standard library.
>
> * Deprecate the Indexable protocols with a message indicating that they
>   will be gone in Swift 4.  These protocols are implementation details
>   of the standard library designed to work around language limitations
>   that we expect to be gone in Swift 4.  There's no reason for anyone to
>   ever touch these; users should always use a corresponding Collection
>   protocol (e.g. instead of MutableIndexable, use MutableCollection).
>
> * Deprecate the ExpressibleByStringInterpolation protocol with a
>   message indicating that its design is expected to change.  We know
>   this protocol to be mis-designed
>   (https://bugs.swift.org/browse/SR-1260) and limited
>   (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>   for Swift 3.  If we knew what the new design should look like, we
>   might be able to calculate that the current API is supportable in a
>   forward-compatible way (as we do for Comparable).  Unfortunately, we
>   do not.
>
> * Rename Streamable to TextOutputStreamable and add a deprecated
>   Streamable typealias for it.  Now that OutputStream been renamed to
>   TextOutputStream, we should also move Streamable out of the way.
>
> Deprecation is being proposed instead of underscoring or renaming
> because it allows existing code to keep working (with warnings).  At
> this late stage, it would be bad to actually break anything.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Maximilian Hünenberger via swift-evolution]

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 um 14:41 schrieb Björn Forster via swift-evolution 
> :
> 
> Hello Swift community,
> to make use of Swift more appealing and useful for science, engineering and 
> finance and everything else involving actually calculating things, I think it 
> would be a big step forward if Swift would ship with its own math/numerics 
> library.
> 
> Wouldn't it be great if Swift would offer functionality similar to Numpy in 
> its native math lib? It think it would be great to have a "standard" 
> annotation for vector arithmetic that the Swift community has agreed on and 
> that scientific packages can build on.
> 
> Which functionality should be covered by a Swift's math lib and where should 
> be drawn the line?
> 
> Any thoughts?
> 
> (If it is not the right time now to talk this topic, as it is not mentioned 
> in the goals for Swift 4 by Chris, I apologize for bringing this up now. But 
> I think then this should be discussed later at some point not in the infinite 
> future)  
> 
> Björn
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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 many of the standard
library's design decisions for years to come.  What we only realized
very recently is that, although Swift 3.0 is *not* shipping with a
stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
code creates similar implications when it comes to certain protocols,
today.  Especially where these protocols show up in refinement
hierarchies, we can't keep Swift 3 code working in the future without
carrying them forward into future libraries.

The proposed changes are as follows:

* Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
  This component is really only useful for playgrounds, and doesn't
  belong in the standard library.

* Deprecate the Indexable protocols with a message indicating that they
  will be gone in Swift 4.  These protocols are implementation details
  of the standard library designed to work around language limitations
  that we expect to be gone in Swift 4.  There's no reason for anyone to
  ever touch these; users should always use a corresponding Collection
  protocol (e.g. instead of MutableIndexable, use MutableCollection).

* Deprecate the ExpressibleByStringInterpolation protocol with a
  message indicating that its design is expected to change.  We know
  this protocol to be mis-designed
  (https://bugs.swift.org/browse/SR-1260) and limited
  (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
  for Swift 3.  If we knew what the new design should look like, we
  might be able to calculate that the current API is supportable in a
  forward-compatible way (as we do for Comparable).  Unfortunately, we
  do not.

* Rename Streamable to TextOutputStreamable and add a deprecated
  Streamable typealias for it.  Now that OutputStream been renamed to
  TextOutputStream, we should also move Streamable out of the way.

Deprecation is being proposed instead of underscoring or renaming
because it allows existing code to keep working (with warnings).  At
this late stage, it would be bad to actually break anything.

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dan Stenmark via swift-evolution]

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 language's use of 
Green Threads and how the runtime handles the heavy lifting of multiplexing and 
scheduling them.  What are some of the strengths and weaknesses the Swift team 
sees to Go's approach?

Dan

(DISCLAIMER: I'm posting this for academic reasons, not as a pitch.  While the 
Swift team's responses may inform opinions on the matter, I do not want this to 
turn into a 'this is how I think Swift should do concurrency' debate.  That 
discussion will come when it comes.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 may violate user expectations that `a(b(c))` generally entails
invoking both b(_:) and a(_:).

IMO, the core team's original rationale for having a generic enum rather
than generic functions is sound, and I think I've come around to sharing
Dave's opinion that ofValue and non-ofValue facilities should distinguish
themselves from each other as much as possible to avoid confusion about
their behavior when the argument is T.self vs. T.Type.

In the alternatives section, I've also included a sketch of an argument for
why having duplicative API for non-ofValue facilities might be less than
preferable.
On Tue, Aug 9, 2016 at 12:57 Erica Sadun  wrote:

> 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<*Int*>.size`
> and `MemoryLayout.size(ofValue: *2*)`, with T inferred from the
> `size(ofValue:)` argument type.
>
> * Will it benefit the compiler to use autoclosure as previously discussed
> to avoid evaluation? Or is that unnecessary?
> * With some list members requesting a single namespaced set of functions
> that align with the original version of 101, is there any advantage to
> adopting the following non-generic enum design?
>
> public enum MemoryLayout {
> public static func size(ofValue _: T) -> Int { ... }
> public static func stride(ofValue _: T) -> Int { ... }
> public static func alignment(ofValue _: T) -> Int { ... }
> public static func size(of _: T.Type) -> Int { ... }
> public static func stride(of _: T.Type) -> Int { ... }
> public static func alignment(of _: T.Type) -> Int { ... }
> }
>
> * If not, should the remaining 3 functions be added to `MemoryLayout`
> as a courtesy for those who feel it reads better?
>
> -- E
>
> On Aug 7, 2016, at 12:18 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0136-memory-layout-of-values.md
>
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution
> mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of
> Swift. When writing your review, here are some questions you might
> want to answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
>  change to Swift?
> * Does this proposal fit well with the feel and direction of
>  Swift?
> * If you have used other languages or libraries with a similar
>  feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a
>  quick reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> Dave Abrahams
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 compiler to use autoclosure as previously discussed to 
avoid evaluation? Or is that unnecessary?
* With some list members requesting a single namespaced set of functions that 
align with the original version of 101, is there any advantage to adopting the 
following non-generic enum design?

public enum MemoryLayout {
public static func size(ofValue _: T) -> Int { ... }
public static func stride(ofValue _: T) -> Int { ... }
public static func alignment(ofValue _: T) -> Int { ... }
public static func size(of _: T.Type) -> Int { ... }
public static func stride(of _: T.Type) -> Int { ... }
public static func alignment(of _: T.Type) -> Int { ... }
}

* If not, should the remaining 3 functions be added to `MemoryLayout` as a 
courtesy for those who feel it reads better?

-- E

> On Aug 7, 2016, at 12:18 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 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:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0136-memory-layout-of-values.md
> 
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution
> mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of
> Swift. When writing your review, here are some questions you might
> want to answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a
>  change to Swift?
>   * Does this proposal fit well with the feel and direction of
>  Swift?
>   * If you have used other languages or libraries with a similar 
>  feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a
>  quick reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> Dave Abrahams
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI of throwing

[Joe Groff via swift-evolution]

> 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* nocapture readnone, 
>> %swift.error** nocapture) #0 {
>> entry:
>>   %2 = tail call { %swift.error*, %swift.opaque* } @swift_allocError(/* snip 
>> */)
>>   %3 = extractvalue { %swift.error*, %swift.opaque* } %2, 0
>>   store %swift.error* %3, %swift.error** %1, align 8
>>   ret void
>> }
> 
> This means that call sites for throwing functions must always check if an 
> exception occurred. This makes it essentially equivalent to returning an 
> error code in addition to the function's actual return type.

Note that we don't currently implement the error handling ABI as we eventually 
envision it. The plan is for LLVM to eventually lower that %swift.error** 
parameter to a normally callee-preserved register, which is set to zero by the 
caller before the call. That way, nonthrowing and 'rethrows' functions can 
cheaply be used where throwing functions are expected, since a nonthrowing 
callee will just preserve the zero the caller put in the register. And since 
ARM64 has a handy 'branch if nonzero' instruction, this means that a throwing 
call would only cost two instructions on the success path:

movz wError, #0
bl _function_that_may_throw
cbnz wError, catch
; happy path continues

Non-taken branches are practically free with modern predictors, and (as Chris 
noted in his reply) there's no need for the compiler to emit massive unwind 
metadata or the runtime to interpret that metadata, so the impact on the 
success path is small and the error path is still only a branch away. As Chris 
also noted, we only want people using 'throw' in places where errors are 
expected as part of normal operation, such as file IO or network failures, so 
we don't *want* to overly pessimize failure branches.

-Joe

> 
> On the other hand, there are exception handling mechanisms where the 
> execution time cost in the success case is zero, and the error case is 
> expensive. When you throw, the runtime walks through the return addresses on 
> the stack to find out if there's an associated catch block that can handle 
> the current exception. Apple uses this mechanism (with the Itanium C++ ABI) 
> for C++ and Objective-C exceptions, at least on x86_64.
> 
> Other compiler engineers, like Microsoft's Joe Duffy, have determined that 
> there actually is a non-trivial cost associated to branching for error codes. 
> In exchange for faster error cases, you get slower success cases. This is 
> mildly unfortunate for throwing functions that overwhelmingly succeed.
> 
> As Fernando Rodríguez reports in another thread, you have many options to 
> signal errors right now (I took the liberty to add mechanisms that he didn't 
> cover):
> 
>   • trapping
>   • returning nil
>   • returning an enum that contains a success case and a bunch of error 
> cases (which is really just a generalization of "returning nil")
>   • throwing
> 
> With the current implementation, it seems to me that the main difference 
> between throwing and returning an enum is that catch works even when you 
> don't know what you're catching (but I really hope that we can get typed 
> throws for Swift 4, because unless you actually don't know what you're 
> catching, this feels like an anti-feature). However, if throwing and 
> returning an enum had different-enough performance characteristics, the 
> guidance could become:
> 
>   • return an enum value if you expect that the function will fail often 
> or if recovery is expected to be cheap;
>   • throw if you expect that the function will rarely fail or if recovery 
> is expected to be expensive for at least one failure reason (for example, if 
> you'd have to re-establish a connection after some network error, or if you'd 
> have to start over some UI process because the user picked a file that was 
> deleted before it could be opened).
> 
> Additionally, using the native ABI to throw means that you can throw across 
> language boundaries, which might be useful in the possible but distant future 
> in which Swift interops with C++. Even though catching from the other 
> language will probably be tedious, that would already be useful in language 
> sandwiches to unwind correctly (like in Swift that calls C++ that calls 
> Swift, where the topmost Swift code throws).
> 
> I don't really know what to expect in terms of discussion, especially since 
> it may boil down to "we're experts in this fields and you're just peasants" 
> or "the cost of changing this isn't worth the benefit". Still, I'd like some 
> more insight into why Swift exceptions don't use the same mechanism as C++ 
> exceptions and Objective-C exceptions. The error handling rationale 

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

[Wallacy via swift-evolution]

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:

> -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.
>
> -Ofunction
> Is a dummy example for other example.
>
> On Tue, Aug 9, 2016 at 11:21 PM, Félix Cloutier  wrote:
>
>> 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 <
>> swift-evolution@swift.org> a écrit :
>>
>> 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 loop or maths optimization or allow developers to
>> fine-tuning in various area, we could add more options to compiler.
>>
>> -OLoop (Optimize loop with safety)
>> -OFunc (Optimize function calls)
>> and so on.
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Keith Smiley via swift-evolution]

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 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 started using *Swift 3.0 Dev Preview
> 1*
>
>
> *Best Regards,*
>
> *Sunil*
>
> --
>
>
> Disclaimer: The information contained in this communication, including
> attachments is privileged and confidential. It is intended only for the
> exclusive use of the addressee. If the reader of this message is not the
> intended recipient, or the employee or agent responsible for delivering it
> to the intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited. If
> you have received this communication in error please notify us by e-mail at
> supp...@techendeavour.com  Thank you.

> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Muse M via swift-evolution]

-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.

-Ofunction
Is a dummy example for other example.

On Tue, Aug 9, 2016 at 11:21 PM, Félix Cloutier  wrote:

> 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 <
> swift-evolution@swift.org> a écrit :
>
> 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 loop or maths optimization or allow developers to
> fine-tuning in various area, we could add more options to compiler.
>
> -OLoop (Optimize loop with safety)
> -OFunc (Optimize function calls)
> and so on.
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Sunil Pandey via swift-evolution]

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 started using *Swift 3.0 Dev Preview
1*


*Best Regards,*

*Sunil*

-- 


Disclaimer: The information contained in this communication, including 
attachments is privileged and confidential. It is intended only for the 
exclusive use of the addressee. If the reader of this message is not the 
intended recipient, or the employee or agent responsible for delivering it 
to the intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. If 
you have received this communication in error please notify us by e-mail at 
supp...@techendeavour.com  Thank you.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

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 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 loop or maths optimization or allow developers to fine-tuning 
> in various area, we could add more options to compiler.
> 
> -OLoop (Optimize loop with safety)
> -OFunc (Optimize function calls)
> and so on.
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI of throwing

[Félix Cloutier via swift-evolution]

> “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 several million hits a day. 
Management loves to use the percentage of succeeding web requests as a measure 
of overall health. The problem with that metric is that when a web request 
fails, clients fall in an unhealthy state and stop issuing requests for a 
while. Therefore, one failing request prevents maybe twenty more that would all 
have failed if the client hadn't bailed out, but these don't show in 
statistics. This makes us look much better than we actually are.

If I had any amount of experience with DTrace, I'd write a script that logs 
syscall errors to try and see how the programs that I use react to failures. 
I'm almost certain that when one thing stops working, most programs backs out 
of a much bigger process and don't retry right away. When a program fails to 
open a file, it's also failing to read/write to it, or whatever else people 
normally do after they open files. These things are also expensive, and they're 
rarely the type of things that you need to (or even just can) retry in a tight 
loop. My perception is that the immediate cost of failing, even with expensive 
throwing, is generally dwarfed by the immediate cost of succeeding, so we're 
not necessarily losing out on much.

And if that isn't the case, there are alternatives to throwing that people are 
already embracing, to the point where error handling practices seem fractured.

>> I don't really know what to expect in terms of discussion, especially since 
>> it may boil down to "we're experts in this fields and you're just peasants”
> 
> I’m not sure why you think the Swift team would say something that 
> derogatory.  I hope there is no specific action that has led to this belief. 
> If there is, then please let me know.

Of course not. All of you have been very nice and patient with us peasants, at 
least as far as "us" includes me. :) This was meant as a light-hearted 
reflection on discussing intimate parts of the language, where my best 
perspective is probably well-understood desktop/server development, whereas the 
core team has to see that but also needs a high focus on other things that 
don't even cross my mind (or at least, that's the heroic picture I have of you 
guys).

For instance, my "expensive" stops at "takes a while". Your "expensive" might 
mean "takes a while and drains the very finite energy reserves that we have on 
this tiny device" or something still more expansive. These differences are not 
always immediately obvious.

>>  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 
> analysis doesn’t translate over.

The analysis was (probably?) done over C++ and HRESULTs but with the intention 
of applying it to another language (Midori), and it most likely validated the 
approach of other languages (essentially everything .NET-based). Several 
findings of the Midori team are being exported to Microsoft's new APIs, notably 
the async everywhere and exceptions everywhere paradigms, and these APIs are 
callable from both so-called managed programs (GCed) and unmanaged programs 
(ref-counted).

Swift operations don't tend to throw very much, which is a net positive, but it 
seems to me that comparing the impact of Swift throws with another language's 
throws is relatively fair. C# isn't shy of FileNotFoundExceptions, for instance.

> Yes, and many C++ projects build with -fno-exceptions because of the huge 
> code and metadata bloat associated with them.  This is one of many mistakes 
> in C++/Java/etc that we do not want to repeat with Swift.  Additionally, 
> unlike Java, Swift doesn’t generally have the benefit of a JIT compiler that 
> can lazily create these structures on demand.

Yes. I believe that you are familiar with a couple of such C++ projects. :)

As we've seemingly agreed, Swift only needs metadata and code for functions 
that call functions that throw. Also, I understand that we don't need EH tables 
with the current approach, but my understanding is that the cleanup code needs 
to exist regardless of how control is transferred to it. (I have no notion of 
how big EH table entries have to be, so I won't attempt any comparison with the 
size of the equivalent dispatch code. I'm pretty sure that it's unfavorable.)

All in all, I guess that this is an area of Swift that goes against trends that 
are overall satisfying in my domain. Of course, I'm writing all of this because 
I like Swift and I want an ABI that will make it the best choice (or close) for 
the things that I want to do with it. I'm a little concerned that what's best 
for a 

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

[Will Field-Thompson via swift-evolution]

** 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 design I think of, so this is a +1
from me.

I don't mind the `.of(_:)` syntax suggested in the original proposal
either, but I think it's probably (especially with the `@autoclosure`) a
bit too clever for its own good. That is, it would be especially difficult
to discover.

** Is the problem being addressed significant enough to warrant a change to
Swift?*
I would *not* be in favor leaving it out as Brent Royal-Gordon suggested,
because I don't think it's overly specialized. This is one of those things
that you don't think will crop up until it does (like in the stdlib).

** Does this proposal fit well with the feel and direction of Swift?*
Yes.

** If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?*
Long-time fan of `sizeofValue`.

** How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?*
A quick reading of the proposal and the review thread.

Best,

Will

On Tue, Aug 9, 2016 at 10:36 AM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 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 a
>> variable will emerge from the enhanced existential proposals. If one does,
>> we will be able to use it here:
>>
>> MemoryLayout.size
>> MemoryLayout.stride
>> MemoryLayout.size
>>
>> (You could use `size(ofValue:)` and friends with more complicated
>> expressions, but that would mean evaluating them for no good reason. I'd
>> say using `size(ofValue:)` with anything other than a simple variable is
>> probably a smell.)
>>
>> So that means this is:
>>
>> 1. A specialized feature,
>> 2. Probably used far more by the standard library than anything else,
>> 3. Which is a mere convenience,
>> 4. Can be trivially added by any user who wants it,
>> 5. And may no longer be necessary by the time generics are where we want
>> them to be.
>>
>> So why the rush? Why not keep the standard library's implementation
>> private to the standard library?
>>
>
> There's plenty offered by the standard library that _app_ developers might
> not touch very frequently, but since, for example, we're encouraging people
> to start their own matrix algebra library, types like ManagedBuffer
> and--yes--MemoryLayout are probably just as important for those use cases
> as it is for the standard library itself.
>
> To the extent that, as Dave might put it, usage in the standard library
> helps us to "discover" the right API to expose, the experience of
> implementing SE-0101 has been informative, I think. IMO, the migration
> story for a project that *does* need an *ofValue facility could be much,
> much better than having the user reimplement a privately available method,
> and it is possible to deliver an improvement on the Swift 3 timeline.
>
> Of course, more powerful generics are going to be a huge boon for Swift 4,
> but surely it'd be wiser not to omit Swift 3 facilities on hypothesized
> directions for the next version.
>
> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 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 a
> variable will emerge from the enhanced existential proposals. If one does,
> we will be able to use it here:
>
> MemoryLayout.size
> MemoryLayout.stride
> MemoryLayout.size
>
> (You could use `size(ofValue:)` and friends with more complicated
> expressions, but that would mean evaluating them for no good reason. I'd
> say using `size(ofValue:)` with anything other than a simple variable is
> probably a smell.)
>
> So that means this is:
>
> 1. A specialized feature,
> 2. Probably used far more by the standard library than anything else,
> 3. Which is a mere convenience,
> 4. Can be trivially added by any user who wants it,
> 5. And may no longer be necessary by the time generics are where we want
> them to be.
>
> So why the rush? Why not keep the standard library's implementation
> private to the standard library?
>

There's plenty offered by the standard library that _app_ developers might
not touch very frequently, but since, for example, we're encouraging people
to start their own matrix algebra library, types like ManagedBuffer
and--yes--MemoryLayout are probably just as important for those use cases
as it is for the standard library itself.

To the extent that, as Dave might put it, usage in the standard library
helps us to "discover" the right API to expose, the experience of
implementing SE-0101 has been informative, I think. IMO, the migration
story for a project that *does* need an *ofValue facility could be much,
much better than having the user reimplement a privately available method,
and it is possible to deliver an improvement on the Swift 3 timeline.

Of course, more powerful generics are going to be a huge boon for Swift 4,
but surely it'd be wiser not to omit Swift 3 facilities on hypothesized
directions for the next version.

--
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[João Pinheiro via swift-evolution]

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 
>> > wrote:
>> 
>> This proposal [gist 
>> ] is 
>> the result of the discussions from the thread "Prohibit invisible characters 
>> in identifier names 
>> ". I hope 
>> it's still on time for inclusion in Swift 3.
> 
> Hi João,
> 
> Unfortunately, we’re out of time to accept new proposals.  Tomorrow is the 
> last day for *implementation* work on source breaking changes to be done.  We 
> can talk about this next week for Swift 3.x or Swift 4.
> 
> -Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl via swift-evolution]

> 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 “ofValue”.
> 
> The problem with “ofInstance” is that a class instance will be reported
> to be the same size as Int.  Most people think of a class instance as
> the place where its stored properties live, not the reference.

Is there a way to get the size of the stored properties? I had a look but 
couldn’t find one.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 a variable 
will emerge from the enhanced existential proposals. If one does, we will be 
able to use it here:

MemoryLayout.size
MemoryLayout.stride
MemoryLayout.size

(You could use `size(ofValue:)` and friends with more complicated expressions, 
but that would mean evaluating them for no good reason. I'd say using 
`size(ofValue:)` with anything other than a simple variable is probably a 
smell.)

So that means this is:

1. A specialized feature,
2. Probably used far more by the standard library than anything else,
3. Which is a mere convenience,
4. Can be trivially added by any user who wants it,
5. And may no longer be necessary by the time generics are where we want them 
to be.

So why the rush? Why not keep the standard library's implementation private to 
the standard library?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI of throwing

[Goffredo Marocchi via swift-evolution]

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 that there is an impact. 
>> 
>> C++ and Swift are completely different languages in this respect, so the 
>> analysis doesn’t translate over.
> 
> I believe the language in question was a native-compiled C# variant, not C++.
> 
> However, I suspect the numbers from Midori's experiment may not hold up in 
> Swift.

Ah, there is where the study was from/about. There was actually a great blog by 
one of the main engineers about Project Midolo and the tales of its Safeties 
:). The reaction to it and the pushback in the Windows community make me think 
that either they were theoretical baboons or geniuses as sometimes quoting that 
project can be so polarising :).

> Midori used a generational mark-and-sweep garbage collector, so it didn't 
> need to write implicit `finally` blocks to release objects owned by stack 
> frames. Swift would. That could easily eat up the promised 7% code size 
> savings, and the reduced ability to jump past frames could similarly damage 
> the speed improvements.
> 
> I'm not saying I have the numbers to prove that it does; I don't. But given 
> our different constraints, there are good reasons to doubt we'd see the same 
> results.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI of throwing

[Brent Royal-Gordon via swift-evolution]

> 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 
> analysis doesn’t translate over.

I believe the language in question was a native-compiled C# variant, not C++.

However, I suspect the numbers from Midori's experiment may not hold up in 
Swift. Midori used a generational mark-and-sweep garbage collector, so it 
didn't need to write implicit `finally` blocks to release objects owned by 
stack frames. Swift would. That could easily eat up the promised 7% code size 
savings, and the reduced ability to jump past frames could similarly damage the 
speed improvements.

I'm not saying I have the numbers to prove that it does; I don't. But given our 
different constraints, there are good reasons to doubt we'd see the same 
results.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution