Re: [swift-evolution] [Meta] Proposal status page

It is, read here: http://webapps.stackexchange.com/a/42555 --  Adrian Zubarev Sent with Airmail Am 6. September 2016 um 08:12:36, Jacob Bandes-Storch via swift-evolution (swift-evolution@swift.org) schrieb: Is it possible to have a repo named apple.github.io, and still allow individual repos

Re: [swift-evolution] Swift 3 Ranges

> On 6 Sep 2016, at 07:39, David Hart via swift-evolution > wrote: > > I have the impression we exchanged flexibility for correctness (the ability > to represent 0.. > Or am I missing something? > > On 6 Sep 2016, at 08:15, David Hart via swift-evolution > mailto:swift-evolution@swift.org>>

[swift-evolution] [Idea] Further directions for id-as-Any

In the current Swift 3 betas, value types can now be passed into Objective-C as opaque box objects. A couple of reviews are currently running which tweak this bridging, exposing Optionals and NSValue/NSNumber-compatible types in more natural ways. These are all Good Things. I'd like to look ahea

Re: [swift-evolution] [Meta] Proposal status page

> On 6 Sep 2016, at 07:11, Jacob Bandes-Storch wrote: > > Is it possible to have a repo named apple.github.io, and still allow > individual repos having their own pages (like > apple.github.io/swift-evolution)? The `username.github.io` and `username.github.io/projectname` combination works f

[swift-evolution] SPM support for branches and commits

Hi, Our code is almost always developed and pushed in small incremental changes. When we implement critical amount of changes in our code, we push new version. When adding dependencies to Package.swift file, we supply their repository url and version we want to use. However, differentiating code

Re: [swift-evolution] SPM support for branches and commits

I think that the ability to fetch a branch or a commit may be interesting (basically anything that git understands), would be nice, but with the caveat that for production use it is far better to use à fixed version (i.e. a tag). We do not want that most packages are used by specifying the master

Re: [swift-evolution] SPM support for branches and commits

Yes, I agree that tags are far better option for production use, but development process stage would certainly benefit from possibility to track specific branch or commit. Having to rely completely on versioned tags in development stage would not be easy nor very productive. Said On September 6,

Re: [swift-evolution] SPM support for branches and commits

+1 here. It becomes much more crucial when you work with finely grained projects with each module in its own repo. Making a new release when you push a fix becomes too much of job to do. On Tue, Sep 6, 2016 at 5:08 PM, Said Sikira via swift-evolution < swift-evolution@swift.org> wrote: > Yes, I a

[swift-evolution] pattern matching on variable-sized data type

Hello, I would like to suggest an additive evolution to Swift that might be in scope of phase 1 of Swift 4 (because it might have an impact on the ABI). The idea is to extend the pattern matching abilities of Swift to enable a recursive programming style that’s very common in languages such as

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

For a wrapper, are there any public hooks into dyld that allow us to do anything meaningful with #dsoHandle on prior OS? Without that, and without using #dsoHandle, wrapping os_log is essentially useless. Cheers! Zachary Waldowski z...@waldowski.me On Mon, Sep 5, 2016, at 10:59 AM, Douglas G

Re: [swift-evolution] pattern matching on variable-sized data type

The recursive call should obviously read return 〘 a-b 〙 ⋙ listOfDifferenceOfListElements(tail) Jean-Denis > On 06 Sep 2016, at 16:48, Jean-Denis Muys wrote: > > Hello, > > I would like to suggest an additive evolution to Swift that might be in scope > of phase 1 of Swift 4 (because it mig

Re: [swift-evolution] pattern matching on variable-sized data type

You can process lists using pattern matching today: enum List { case Nil indirect case Cons(T, List) } let list: List = .Cons(2, .Cons(3, .Nil)) switch list { case .Nil: ... case .Cons(let x, .Nil): ... case .Cons(let x, .Cons(let y, .Nil)): ... default: handleLongList(list

Re: [swift-evolution] SPM support for branches and commits

(+swift-build-dev, which is more focused for SwiftPM work) Hi Said, I agree, this is something we need. One of the things that a complete proposal for adding this needs is a precise definition for the workflow and exploration about the impact on other features. Some of my questions are: 1. Wh

[swift-evolution] pattern matching on variable-sized data type

Hello, I would like to suggest an additive evolution to Swift that might be in scope of phase 1 of Swift 4 (because it might have an impact on the ABI). The idea is to extend the pattern matching abilities of Swift to enable a recursive programming style that’s very common in languages such as

Re: [swift-evolution] #pragma

> > I understand that maybe a compiler shouldn't lose time handling `#pragma > options`, but giving semantics to source comment, I think it can be dangerous > and misunderstood. Could you elaborate what could be dangerous or misunderstood? Rien. ___

Re: [swift-evolution] [Idea] Further directions for id-as-Any

This might be useful for some cases, but I have some concerns about tying serialization to this. I would rather see a Swift-centric rethinking of serialization than having the runtime dynamically register Objective-C classes anytime I want to serialize something. Plus, that seems like it's leaving

Re: [swift-evolution] SPM support for branches and commits

+1 My first time saying anything on the distribution. Working on Swift 3 migration, a lot of github projects have an non-versioned swift3 branch. I've had to fork projects and create my own version tags... A lot of unnecessary work. Cheers, CB > On Sep 6, 2016, at 12:06, Daniel Dunbar via swi

Re: [swift-evolution] [swift-dev] [Swift 4] Organizing source stability

> On Jul 29, 2016, at 21:13, Chris Lattner via swift-dev > wrote: > > >> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch > > wrote: >> >> Here are a few thoughts: >> -swift=4 >> -swift-version=4 > > -swift-version seems like the best option to me, but Jordan will

Re: [swift-evolution] pattern matching on variable-sized data type

> On Sep 6, 2016, at 7:47 AM, Jean-Denis Muys via swift-evolution > wrote: > > Hello, > > I would like to suggest an additive evolution to Swift that might be in scope > of phase 1 of Swift 4 (because it might have an impact on the ABI). How would you expect this to have an impact on ABI? M

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

> On Sep 2, 2016, at 7:36 PM, Karl via swift-evolution > wrote: > >> * Does this proposal fit well with the feel and direction of Swift? > > Yes, but I’m not sure about the “Unsafe” part of “UnsafeBytes” — what is > unsafe about getting the byte-representation of a value? > > As I understand

Re: [swift-evolution] [Idea] Further directions for id-as-Any

> On Sep 6, 2016, at 10:02 AM, Will Field-Thompson wrote: > > I would rather see a Swift-centric rethinking of serialization than having > the runtime dynamically register Objective-C classes anytime I want to > serialize something. Plus, that seems like it's leaving Linux users out in > the c

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

> On Sep 5, 2016, at 6:44 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi via swift-evolution >> wrote: >> >> I hope you will not find it too impolite, but this feels like a more >> dogmatic decision than I would like. I agree that macr

Re: [swift-evolution] pattern matching on variable-sized data type

> On Sep 6, 2016, at 7:48 AM, Jean-Denis Muys via swift-evolution > wrote: > > Hello, > > I would like to suggest an additive evolution to Swift that might be in scope > of phase 1 of Swift 4 (because it might have an impact on the ABI). This is a purely additive change, I can’t imagine how

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

Hello Chris, What would you suggest for people that want to use Swift, but cannot set a target of iOS 10+? Could the compiler/backward compatibility library intercept those calls in older OS's and replace them with simple NSLog's with some data added to the logged string? On Tue, Sep 6, 2016 at 1

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

> On Sep 2, 2016, at 4:58 PM, Gwynne Raskind via swift-evolution > wrote: > >> On Sep 2, 2016, at 17:50, Douglas Gregor wrote: >> >> Hello Swift community, >> >> The review of SE-0140 "Bridge Optional As Its Payload Or NSNull" begins now >> and runs through September 8, 2016. The proposal i

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution > wrote: > >> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution >> wrote: >> >> The goal of the review process is to improve the proposal under review >> through constructive criticism and, eventually, determine t

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

> On Sep 6, 2016, at 3:16 PM, Goffredo Marocchi wrote: > > Hello Chris, > > What would you suggest for people that want to use Swift, but cannot set a > target of iOS 10+? Could the compiler/backward compatibility library > intercept those calls in older OS's and replace them with simple NSLo

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

> On Sep 6, 2016, at 4:50 PM, Joe Groff wrote: > > >> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution >> wrote: >> >>> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> The goal of the review process is to improve the proposal under review >

Re: [swift-evolution] #pragma

Just another consideration: the consequence could be about avoiding any `#pragma` (or equivalent), semantic instructions out of comments, those, in my opinion, should be fully ignored by compiler and IDE: knowing that comments are not ignored  by compiler or IDE, a developer may think not using

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

> On Sep 6, 2016, at 5:11 PM, Douglas Gregor wrote: > >> >> On Sep 6, 2016, at 4:50 PM, Joe Groff wrote: >> >> >>> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution >>> wrote: >>> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution wrote: The

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

Sent from my iPhone > On Sep 6, 2016, at 5:21 PM, Joe Groff wrote: > > >>> On Sep 6, 2016, at 5:11 PM, Douglas Gregor wrote: >>> >>> >>> On Sep 6, 2016, at 4:50 PM, Joe Groff wrote: >>> >>> > On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution > wrote: > >

Re: [swift-evolution] [Idea] Further directions for id-as-Any

> On Sep 6, 2016, at 5:19 AM, Brent Royal-Gordon via swift-evolution > wrote: > > In the current Swift 3 betas, value types can now be passed into Objective-C > as opaque box objects. A couple of reviews are currently running which tweak > this bridging, exposing Optionals and NSValue/NSNumbe

Re: [swift-evolution] #pragma

I'm not sure I understand. Swift comments are parsed. Are you saying that this is a problem? If so, why do you think it's a problem? On Tue, Sep 6, 2016 at 7:19 PM, isidoro carlo ghezzi < isidoro.ghe...@icloud.com> wrote: > Just another consideration: the consequence could be about avoiding any

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

> On Sep 6, 2016, at 7:11 PM, Douglas Gregor wrote: > > I *think* Charles is saying something slightly different here, and it’s a > viewpoint I hadn’t considered before. > > We agree that there should be some kind of diagnostic when putting an > optional into an Any, because it’s probably not

Re: [swift-evolution] Renaming for Protocol Conformance

> I argue the same thing applies here. Currently, protocols constrain the API > of conforming types. If a designer has reasoned through their design > correctly, then all is well. If a designer has made bad design choices, then > conforming types are constrained to have bad API design. Is that

Re: [swift-evolution] [Review] SE-0139: Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

* What is your evaluation of the proposal? I majorly support this proposal, particularly the completion of numeric bridging. I would almost regarding the existing behavior as a bug. As a user, I was very surprised that `Int8` and friends did not bridge to `NSNumber`, and it has actually been th

Re: [swift-evolution] [Meta] Proposal status page

> On Sep 6, 2016, at 05:47, Ben Rimmington via swift-evolution > wrote: > > > >> On 6 Sep 2016, at 07:11, Jacob Bandes-Storch wrote: >> >> Is it possible to have a repo named apple.github.io, and still allow >> individual repos having their own pages (like >> apple.github.io/swift-evoluti

Re: [swift-evolution] Renaming for Protocol Conformance

On Tue, Sep 6, 2016 at 8:06 PM, Jonathan Hull wrote: > > I argue the same thing applies here. Currently, protocols constrain the > API of conforming types. If a designer has reasoned through their design > correctly, then all is well. If a designer has made bad design choices, > then conforming t

Re: [swift-evolution] [Meta] Proposal status page

It'd be great to see swift.org as just another repo on github.com/apple via GitHub Pages ;-) Jacob On Tue, Sep 6, 2016 at 8:45 PM, Jordan Rose wrote: > > > On Sep 6, 2016, at 05:47, Ben Rimmington via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > > >> On 6 Sep 2016, at 07:11

Re: [swift-evolution] Renaming for Protocol Conformance

On Sep 6, 2016, at 6:06 PM, Jonathan Hull via swift-evolution wrote: >> I'm not entirely sure on my position, though. To be convinced otherwise, I'd >> need to see a compelling real-world use case that demonstrates all of the >> following: >> >> - Safety: perhaps, with protocols, unlike class

Re: [swift-evolution] SE-0138 UnsafeBytes

> On Sep 2, 2016, at 5:14 PM, Andrew Trick via swift-evolution > wrote: > >> >> On Sep 2, 2016, at 11:14 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Thu Sep 01 2016, Andrew Trick wrote: >> >>> I’m resending this for Review Manager Dave A. because the announce list is >>>

Re: [swift-evolution] [swift-evolution-announce] SE-0138 UnsafeBytes

> On Sep 2, 2016, at 1:08 PM, Andrew Trick via swift-evolution > wrote: > >> >> On Sep 2, 2016, at 9:31 AM, Tony Parker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Andy, Dave, >> >> I have two major objections to this proposal. >> >> The first is timing. It is