> On Jul 30, 2016, at 3:21 PM, Colin Barrett wrote:
>
>> - You can choose to use the memory ownership features by adding extra
>> annotations, giving better performance and control over ARC. Right now we
>> have very limited options for avoiding ARC overhead in
> On Jul 30, 2016, at 1:48 PM, Ted F.A. van Gaalen
> wrote:
>
> Hi Chris,
>
> thanks for the tip about Hirundo app!
>
> A positive side-effect of removing the classical for;; loop
> (yes, it’s me saying this :o) is that it forces me to find
> a good and generic
> On Jul 30, 2016, at 9:19 PM, Robert Hedin via swift-evolution
> wrote:
>
> I thought Chris was pretty clear as well; but what was said was:
>
> "Over the next year, the core team expects to ship two major releases of
> Swift: Swift 3.x in Spring 2017 and Swift 4
I thought Chris was pretty clear as well; but what was said was:
"Over the next year, the core team expects to ship two major releases of
Swift: *Swift 3.x in Spring 2017* and *Swift 4 in Fall 2017*."
I'm know I'm being pedantic, but since 3.0 hasn't been released yet, it
sounds like it should
There is no way Swift 3 doesn't ship with iOS 10 in September.
I think he meant point releases after 3.0 (3.*) will be in 2017 (3 vs 3.* vs 4
was trying to convey this I believe).
Swift 3 has to ship with iOS 10 because lots of us are building and updating to
iOS 10 and using swift 3. Apple
What benefit do Iterator2D and Iterator3D provide that nesting does not?
> On Jul 30, 2016, at 1:48 PM, Ted F.A. van Gaalen via swift-evolution
> wrote:
>
> Hi Chris,
>
> thanks for the tip about Hirundo app!
>
> A positive side-effect of removing the classical
The date I can submit my Swift 3 app to the App Store has significant
impact on my life at the moment. I think Chris' meaning was actually fairly
clear, but I'd also appreciate if the team could spell out an ETA again in
black and white. I'd like to be 100% sure I didn't misunderstand.
On Sat,
My team has been closely following things here and has been looking forward
with great anticipation to using Swift 3 in our production systems.
To that end, I'd like to confirm (or not) that "Swift 3.0" is no longer
expected to ship in "late 2016" as currently reflected on the Swift
Evolution
> On Jul 30, 2016, at 12:21 AM, Chris Lattner via swift-evolution
> wrote:
>
> On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution
> > wrote:
>> I wrote this a few months ago, but we weren't
Hi Chris,
thanks for the tip about Hirundo app!
A positive side-effect of removing the classical for;; loop
(yes, it’s me saying this :o) is that it forces me to find
a good and generic equivalent for it,
making the conversion of my for;;s to 3.0 easier.
which is *not* based on collections or
Does ZenHub have something that even remotely looks like a forum? I can’t find
anything like that on their website. Or is your suggestion that we move all of
swift-evo directly to GitHub?
> I'm open to ZenHub that can be integrate as part of GitHub for discussion,
> pull changes and it makes
> On Jul 30, 2016, at 1:42 AM, Ian Partridge wrote:
>
> On 30 July 2016 at 02:33, Chris Lattner via swift-evolution
> wrote:
>> I’m personally convinced that we don’t get to great string processing
>> without regular expressions (as one
>>
> On Jul 30, 2016, at 2:42 AM, Charlie Monroe via swift-evolution
> wrote:
>
> Given most discussion here is now about Swift 4, I wanted to ask the core
> team what is the proposed course for the 3.x releases - should they contain
> only non-additive changes
Hi Karl,
I started a discussion about such a concept (afair under the label
"compile-time parameters"), and "completing generics" talks about it as well.
Although I think it is quite fundamental (Swift has no arrays of fixed
size(!)), and shouldn't be that hard to implement, I'm not sure if it
I’ve had this idea floating around my head for a little while, and I’m not sure
if it’s either really interesting or totally absurd.
Sorry if it’s not time for ideas like this yet. It’s not really a “proposal”,
but it would be ABI-related I think.
So, the idea: The compiler can generate
Even if we just moved swift-user to a forum as a test, I think it would be
greatly revealing and helpful. It would benefit the most overnight.
It may be difficult to convince people who have used mailing lists for many
years to suddenly move away to something "new". A slow migration on the
+1 for a forum or other editable medium.
On Sat, Jul 30, 2016 at 4:55 PM Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:
> +1 from me as well to anything that allows editing typos after posting.
>
> Charles
>
> On Jul 30, 2016, at 8:22 AM, Haravikk via swift-evolution <
>
+1 from me as well to anything that allows editing typos after posting.
Charles
> On Jul 30, 2016, at 8:22 AM, Haravikk via swift-evolution
> wrote:
>
> But I like sending out my messages then regretting the many typos and
> mistakes I only seem able to notice
But I like sending out my messages then regretting the many typos and mistakes
I only seem able to notice immediately after it's too late to do anything about
it!
(so yeah, +1)
> On 30 Jul 2016, at 12:39, Johannes Neubauer via swift-evolution
> wrote:
>
> +1 to
+1 to move away from mail ;).
Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack
extensively.
[0]: https://slack.com/
[1]: http://www.teamwire.eu/
Von meinem iPhone gesendet
> Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution
> :
>
>
Hey guys,
TL;DR; proposed solution in the second half.
actually, we are already doing something like this without modifying the
language itself here:
https://github.com/crossroadlabs/Regex/blob/swift2.x/Regex/String%2BRegex.swift
It's Scala style (.r notion). Works perfectly with switch
> On 29 Jul 2016, at 17:42, Bram Beernink via swift-evolution
> wrote:
>
> Hi all,
>
> Would it be possible to improve value and move semantics (performance) in
> Swift? Consider this possible Swift code in a future release of Swift:
>
> let array1 : [String] =
This is very interesting, but it'll probably be a little while before I can
fully get my head around it.
One query though; an example mentioned is adding @owns(Element) to the
Generator protocol, but associated types feel a little different to me; you
mention using the strong keyword as an
Given most discussion here is now about Swift 4, I wanted to ask the core team
what is the proposed course for the 3.x releases - should they contain only
non-additive changes (potentially breaking) or should minor additive features
be allowed as well? Given the strict focus of Swift 4, I think
We will need a platform that live near the code (repo). Contextual
switching is expensive for every developers especially lengthy discussions
could have save us man-hours.
On Sat, Jul 30, 2016 at 3:42 PM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:
> I have not enough
On 30 July 2016 at 02:33, Chris Lattner via swift-evolution
wrote:
> I’m personally convinced that we don’t get to great string processing without
> regular expressions (as one
> example), but they are clearly out of scope for Stage 1.
Foundation already has
I am curious if we could find a way/place to talk about larger cross-cutting
syntax issues that may inform the design of several proposals. In other words,
this might be a good time to explicitly look at the forest (vs. the trees) and
brainstorm about the wider picture (which can later be
27 matches
Mail list logo