Re: [swift-evolution] Pitch: Copy constructors for structs

> On Dec 24, 2015, at 1:04 PM, Félix Cloutier wrote: > > At which point does that happen? The O0 SIL for it has an alloc_stack $Point > in main. > > Otherwise, that's hard-to-predict copy elision at work anyway. The alloc_stack is passed into materializeForSet, but it's

Re: [swift-evolution] Proposal: One-past-end array pointers and convertibility of nil for interaction with C APIs

Thanks for your answer! > I think the thing to do is to make two calls: Eeeek, that's exactly what I wanted to avoid (which I actually think is the worst possible solution). > The inout-to-pointer is only available to function argument expressions; it's not even considered in a ternary

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

> On Dec 24, 2015, at 7:51 PM, Alejandro Martinez wrote: > > Absolutely agree Matthew. > My point was that if this is the temporary tradeoff that we have to support > for me is worth it. Having typed throws looks like a great next step to > improving the current error

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 24, 2015, at 3:05 PM, Joe Groff wrote: > >> >> On Dec 24, 2015, at 12:17 PM, Matthew Johnson > > wrote: >> >>> >>> On Dec 24, 2015, at 11:11 AM, Joe Groff >> >

Re: [swift-evolution] Pitch: Copy constructors for structs

Oh well. I thought I had done due diligence! One less thing to be wrong about in the future. Félix > Le 24 déc. 2015 à 16:07:25, Joe Groff a écrit : > > >> On Dec 24, 2015, at 1:04 PM, Félix Cloutier wrote: >> >> At which point does that happen? The O0

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Absolutely agree Matthew. My point was that if this is the temporary tradeoff that we have to support for me is worth it. Having typed throws looks like a great next step to improving the current error system. Curious to see your ideas about that ;) Cheers, Sent from my iPad > On 24 Dec 2015,

Re: [swift-evolution] Epic: Typesafe calculations

I have been working for a couple weeks (since the previous [newtype discussion]( https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001821.html) ) on a related pitch. There seem to me to be multiple ways to solve this problem - a newtype(esque) keyword, struct subtyping, or

Re: [swift-evolution] Pitch: Copy constructors for structs

At which point does that happen? The O0 SIL for it has an alloc_stack $Point in main. Otherwise, that's hard-to-predict copy elision at work anyway. Félix > Le 24 déc. 2015 à 14:40:13, John McCall a écrit : > >> On Dec 23, 2015, at 2:18 PM, Félix Cloutier via

Re: [swift-evolution] Epic: Typesafe calculations

> I'm planning to write a proposal for automatic forwarding. Something like class delegation in Kotlin? Please hurry, I've no work to distract me for the rest of the year, and extending typealias could be a very quick proposal ;-) ___ swift-evolution

Re: [swift-evolution] Proposal - Allow properties in Extensions

Sent from my iPad > On Dec 24, 2015, at 1:31 PM, John McCall wrote: > > >> On Dec 23, 2015, at 10:51 AM, Matthew Johnson wrote: >> >> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution wrote:

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 24, 2015, at 2:05 PM, John McCall wrote: > >> On Dec 24, 2015, at 11:48 AM, Matthew Johnson wrote: >>> On Dec 24, 2015, at 1:31 PM, John McCall wrote: >>> >>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 24, 2015, at 11:11 AM, Joe Groff wrote: > >> >> On Dec 24, 2015, at 5:41 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> >> >> Sent from my iPad >> >>> On Dec 24, 2015, at 5:46 AM, Thorsten

Re: [swift-evolution] Community Proposal: "This Week In Swift" newsletter

I can certainly see where a dedicated newsletter would be ideal if the objective is a detailed look at the week's activity. On the other hand, if an overview in bullet form would be of interest, I would certainly be willing to include a section in the weekly open source newsletter I've been

Re: [swift-evolution] Proposal: Python's indexing and slicing

On 23/12/15 12:45 , swift-evolution-requ...@swift.org wrote: > Date: Tue, 22 Dec 2015 21:12:08 -0800 From: Kevin Ballard > To: Jordan Rose Message-ID: > <1450847528.263398.474637513.2f478...@webmail.messagingengine.com> > > Oh that's a good point, I hadn't

Re: [swift-evolution] [Pitch] Guarding on enum values

Wait, no, there's a problem with that. You can't use `r` in the guard scope because `returnsResult()` might not have succeeded. Félix > Le 24 déc. 2015 à 09:37:36, Félix Cloutier via swift-evolution > a écrit : > > I like that it's consistent with the if syntax

Re: [swift-evolution] Epic: Typesafe calculations

First, of all, I’d love to have a “newtype” equivalent in Swift: +1. But also wanted to mention that my current pattern for this sort of code is to use structs, which has the added advantage (or disadvantage, depending upon your particular use case) of being able to easily specify fewer and

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Hi! I've been following the conversation closely so here are my 2c TL;TR: +1 After proposing solutions for the concerns about conversions this is a clear +1. Overloading the conversion functions is how it works in Rust and I think is a good tradeoff, even without the magical "try!" That Rust

Re: [swift-evolution] ternary operator ?: suggestion

Hi David, I have been using ?( as kind of a more general meaning that there is a question here not that ? is just for optionals. I am fine with using some other character or word if it expresses the idea that the expression returns one of the results based upon the control parameter. ? is kind

Re: [swift-evolution] Proposal: One-past-end array pointers and convertibility of nil for interaction with C APIs

> On Dec 23, 2015, at 5:35 PM, Árpád Goretity via swift-evolution > wrote: > > Hi everyone, > > I was recently trying to use a C API (LLVM for the record) that required > passing an array to a function in the form of a pointer and a size. I > couldn't find a

Re: [swift-evolution] Lambda function syntax

Yeah, I'm not to bothered by this either way. Back to the discussion about closure syntax, maybe? Sent from my iPhone > On 24 Dec 2015, at 14:05, Alan Skipp wrote: > > I'm completely against replacing '->' by ':' it would make unreadable the > declaration of a function

Re: [swift-evolution] Lambda function syntax

> I'm completely against replacing '->' by ':' it would make unreadable the > declaration of a function taking a closure as parameter, or returning one > (among other things). That's definitely right: Two different separators only shift the problem by one level, but hopefully it won't become

Re: [swift-evolution] Epic: Typesafe calculations

> A first tiny step towards more safety would be empowering typealias and > generate warnings when a function is used with the "wrong" parameter type > ("Kelvin" requested, but plain Float given). > Additionally, extensions written for a typealias shouldn't be treated like > extensions for the

Re: [swift-evolution] Lambda function syntax

> I'm completely against replacing '->' by ':' it would make unreadable the > declaration of a function taking a closure as parameter, or returning one > (among other things). > > -- > Pierre I agree with Pierre. Parameter names and functions as arguments or return values are easily

Re: [swift-evolution] Epic: Typesafe calculations

> Search the archives for `newtype`, which is Haskell's version of this feature Thanks for the hint — searching the archives is more complicated as expected ;-), but afaics there haven't been any opposing statements, and the topic just died away without a formal proposal. Any interest reviving

Re: [swift-evolution] Replace "continue" keyword

I think skip would be a better enough choice. > El 24 des 2015, a les 0:10, Douglas Gregor via swift-evolution > va escriure: > > >> On Dec 23, 2015, at 3:09 PM, Rudolf Adamkovič via swift-evolution >> wrote: >> >> Ruby uses "next"

Re: [swift-evolution] Lambda function syntax

Assuming that you are using : for type assignment and -> or => for functions unlabelled functions would have the syntax Int => Int not Int: Int. So func(int : Int, bool: Bool) : Int // would return a value func((int: Int, bool: Bool) : Int => Int would return a function with parameter of int

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Sent from my iPad > On Dec 24, 2015, at 5:46 AM, Thorsten Seitz wrote: > > >> Am 22.12.2015 um 18:30 schrieb Matthew Johnson : >> >> My proposal is specifically suggesting that we treat “initial value” as a >> default rather than an

Re: [swift-evolution] FYI: Apple holiday shutdown

Merry christmas to all pushing Swift forwards (and as well to those who are merely watching)! Thank you for the work you have done, enjoy the free time and don't think about the mess that we amateurs will create here till January ;-) ___

Re: [swift-evolution] Epic: Typesafe calculations

My college calculator had that, and once I discovered it I never went back. For sure, if I did anything remotely scientific with Swift, I would be in love with the feature. I'm not very good with functional programming but that sounds like something functional programming folks would have a

Re: [swift-evolution] Replace "continue" keyword

I don’t think skip is a better word choice either. IMO next is better than skip and I will prefer to use that than skip but as said before, next is not "better enough” as a replacement for continue. > On 24Dec, 2015, at 9:31 PM, Daniel Valls Estella via swift-evolution >