Re: [swift-evolution] Nil-rejection operator

> On Feb 8, 2017, at 12:00 PM, Jack Newcombe via swift-evolution > wrote: > > I propose the introduction of a nil-rejection operator (represented here as > !!) as a complement to the above operators. > . > This operator should allow an equivalent behaviour to the

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

> On Feb 8, 2017, at 4:48 PM, Jan Neumüller via swift-users > wrote: > > May I ask why with so many great open source forums that junk Discourse got > chosen? I'm very perplexed by this decision... I’ve looked at a lot of forum software, and most of the open-source

Re: [swift-evolution] [Pitch] consistent public access modifiers

on Wed Feb 08 2017, Xiaodi Wu wrote: > I agree very much with rationalizing access levels, but I'm not sure I like > this proposal for public vs. closed. How would the compiler stop me from > editing my own code if something is closed? The answer must be that it >

Re: [swift-evolution] Protocol requirement `where` clauses constraining associated types

on Wed Feb 08 2017, Slava Pestov wrote: > Hah, Doug and I were just discussing this. Funny thing; Nate Cook and I were just discussing the same thing today. It seems like this hack we did in the standard library points to a missing language feature; one with possible

Re: [swift-evolution] Protocol requirement `where` clauses constraining associated types

> On Feb 8, 2017, at 10:30 PM, Douglas Gregor wrote: > > >> On Feb 8, 2017, at 10:21 PM, Slava Pestov wrote: >> >> Hah, Doug and I were just discussing this. >> >> In Swift 3.1, we generalized where clauses to allow them to add requirements >> on outer

[swift-evolution] Is it possible to compile swift code to dynamic library ?

Compile swift code to dynamic library(a *.so file which is compatible with C), and let the *.so file can be linked directly by a pure C project. -- with kind regards ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

Hi Ted, Thanks so much for taking time to discuss this with the team. I feel very confident this is going to be a big plus for the community :) David > On 9 Feb 2017, at 01:03, Ted kremenek via swift-evolution > wrote: > > Hi everyone, > > There was a long thread

Re: [swift-evolution] Protocol requirement `where` clauses constraining associated types

> On Feb 8, 2017, at 10:21 PM, Slava Pestov wrote: > > Hah, Doug and I were just discussing this. > > In Swift 3.1, we generalized where clauses to allow them to add requirements > on outer generic parameters. However we did not remove the diagnostic > prohibiting a where

Re: [swift-evolution] Protocol requirement `where` clauses constraining associated types

Hah, Doug and I were just discussing this. In Swift 3.1, we generalized where clauses to allow them to add requirements on outer generic parameters. However we did not remove the diagnostic prohibiting a where clause from being attached to a non-generic method. In theory this can be made to

[swift-evolution] Protocol requirement `where` clauses constraining associated types

In an article on `Collection` today*, Ole Begemann points out that `index(of:)`, along with other `Equatable`- and `Comparable`-constrained `Collection` methods, cannot be overridden. Actually, it *can* be, but only through a private mechanism—there's a `_customIndexOfEquatableElement(_:)`

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

There will be discussions about each of the mailing lists on whether or not to move to Discourse. My preference is that all of the mailing lists move, but the needs of the different lists are slightly different and I didn't want to gate moving swift-evolution to a forum based on the outcome of

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

I don't see any discussions to have Swift Server Side shift to Discourse forum too? On Thursday, February 9, 2017, James Hillhouse via swift-evolution < swift-evolution@swift.org> wrote: > I'll echo Nick and Joshua–thanks Swift Core team for taking the time to > decide on this change. > > Jim >

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

I'll echo Nick and Joshua–thanks Swift Core team for taking the time to decide on this change. Jim > On Feb 8, 2017, at 9:37 PM, Rick Mann via swift-evolution > wrote: > > I second this praise. FWIW, I recently installed Discourse using a > DigitalOcean droplet,

Re: [swift-evolution] SE-0152: Package Manager Tools Version

> The review of SE-0152 "Package Manager Tools Version" begins now and runs > through February 13, 2017. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md > >

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

I second this praise. FWIW, I recently installed Discourse using a DigitalOcean droplet, and it couldn't have been easier. Upgrades are surprisingly easy, too. I have yet to figure out the email integration; I hope you can get that working. I also hope you give some effort to improving on the

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

 This is an awesome decision and a huge enhancement for the Swift community. Thanks (Core Team) for taking the time to entertain the discussion and move forward with what many community members have wanted. Alvarado, Joshua > On Feb 8, 2017, at 5:03 PM, Ted kremenek via swift-evolution

Re: [swift-evolution] Partial Ranges (was: Strings in Swift 4)

Hi Jonathan, It looks like the majority of this is about finite vs infinite collections. This should be a separate thread, and one we certainly need to have, but doesn’t need to be mixed together with the wider one-sided ranges discussion. For now, I think it’s reasonable to say that 1)

Re: [swift-evolution] [Pitch] consistent public access modifiers

Hurray, I cannot wait to get the consistent behavior of open/public protocols. I’m not sure I could follow the idea behind the proposed closed keyboard/access modifier. It almost felt like closed == final public, am I mistaken something here? Furthermore, I really would love if the community

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

Hi Jan, There was a lot of discussion — albeit not on swift-users — and Discourse was the one put forward that those that were pro-forum were most advocating. I actually didn't hear alternative forum software get strongly advocated. Specific things about Discourse (which may be offered by

[swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

Hi everyone, There was a long thread on swift-evolution about whether we should use modern forum software — like Discourse — as an alternative to the mailing lists we have now. After a long discussion, the Core Team has decided to move swift-evolution and swift-users to Discourse. There are

Re: [swift-evolution] I think we need more to our type calculus

> On Feb 8, 2017, at 12:09 PM, Daryle Walker via swift-evolution > wrote: > > I’ve been trying to get the maximum of a list of counts. I started by using > “myCollection.map { $0.myCountProperty }.reduce(0, max)”. Then I thought I > should really use the value

Re: [swift-evolution] [Discussion] mailing list alternative

There has been a tremendous amount of participation on this thread, with some extremely thoughtful analysis of how the mailing list serves the community and the tradeoffs of moving to a forum, like Discourse. I've been thinking about the points made on this thread as well as looking at the

Re: [swift-evolution] [Pitch] consistent public access modifiers

I agree very much with rationalizing access levels, but I'm not sure I like this proposal for public vs. closed. How would the compiler stop me from editing my own code if something is closed? The answer must be that it can't, so I can't see it as a co-equal to open but rather simply a statement

[swift-evolution] [Pitch] consistent public access modifiers

I’ve been thinking a lot about our public access modifier story lately in the context of both protocols and enums. I believe we should move further in the direction we took when introducing the `open` keyword. I have identified what I think is a promising direction and am interested in

Re: [swift-evolution] [swift-build-dev] SE-0152: Package Manager Tools Version

Hello Rick, thanks again for your time and to explain everything in so much detail! :-) > Am 08.02.2017 um 18:34 schrieb Rick Ballard : > > Ultimately, I think no one is thrilled with parsing the Swift tools version > out of a comment, but the feedback we've received so far

Re: [swift-evolution] Nil-rejection operator

As has been mentioned by the core team, syntactic sugar is not in scope for this phase of Swift 4 evolution and was said to be the lowest priority for the next. The bar for adding a new operator is going to be higher than for justifying the continued existence of an existing one. That said, the

Re: [swift-evolution] Nil-rejection operator

It’s absolutely true that this is syntactic sugar, but then so is nil-coalescing where "x ?? y” is syntactic sugar for “x != nil ? x : y”. You can also similarly recreate the nil-coalescing operator in Swift yourself, so I’m not sure that’s a strong argument for any operator being or not being

Re: [swift-evolution] Nil-rejection operator

I picked !! because it seemed to follow somewhat naturally from force-unwrap and nil-coalescing; however, that does depend on how you interpret the syntax of the operator. I interpreted ?? to figuratively mean “? with a default result instead of nil”, and so derived !! As figuratively meaning

Re: [swift-evolution] Nil-rejection operator

This seems to boil down to sugar where `guard let foo = ... else { throw ... }` is spelled `let foo = try ... !! ...`. While the analysis is interesting I don't see that this is an obvious win sufficient for the standard library. As you show it's possible to create for yourself. On Wed, Feb 8,

Re: [swift-evolution] Nil-rejection operator

While I find the concept interesting, I give a big -1 for using the ‘!’ operator for something else that fatal error. > Le 8 févr. 2017 à 21:00, Jack Newcombe via swift-evolution > a écrit : > > Hi all, > > Currently there are a number of different operators for

Re: [swift-evolution] I think we need more to our type calculus

type(of:) is the Swift 3 spelling of what was known in Swift 2 as dynamicType. On Wed, Feb 8, 2017 at 14:09 Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote: > I’ve been trying to get the maximum of a list of counts. I started by > using “myCollection.map { $0.myCountProperty

[swift-evolution] I think we need more to our type calculus

I’ve been trying to get the maximum of a list of counts. I started by using “myCollection.map { $0.myCountProperty }.reduce(0, max)”. Then I thought I should really use the value closest to negative infinity as the base. The problem is how to get that value. The current hard-coded “0” works

[swift-evolution] Nil-rejection operator

Hi all, Currently there are a number of different operators for dealing with optionals that cover most of the use cases. However, I think I’ve identified a missing complement for the existing operators for optionals. Take the following outcomes for interacting with an optional using existing

Re: [swift-evolution] !? operator for ternary conditional unwrapping

For more information about optional chaining read this docs: https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html --  Adrian Zubarev Sent with Airmail Am 8. Februar 2017 um 20:05:31, Adrian Zubarev

Re: [swift-evolution] !? operator for ternary conditional unwrapping

Thanks for teaching me about .map on Optional. Very cool. I agree with the comment of $! misleading, maybe a better alternative would be "??" ? On Wed, Feb 8, 2017 at 5:12 PM Tony Allevato wrote: > What you're asking for is already possible (avoiding the optional

Re: [swift-evolution] !? operator for ternary conditional unwrapping

Swift does already have a great solution in such a scenario. func handler() -> Result? { return callback?.result() } Does the trick. ;) --  Adrian Zubarev Sent with Airmail Am 8. Februar 2017 um 20:02:38, Maxim Veksler (ma...@vekslers.org) schrieb: For example, assume that we're dealing

Re: [swift-evolution] !? operator for ternary conditional unwrapping

Hello Adrian, Please see reply inline. On Wed, Feb 8, 2017 at 4:52 PM Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > You could always write something like this: > > func query(name: String?) -> String { > > let variables_name = String(format: name == nil ? "%@" : "\"%@\"", name

Re: [swift-evolution] !? operator for ternary conditional unwrapping

With Runes , this looks like: (name1 <^> { "\"\($0)\"" }) ?? "null" Runes defines <^> to have lower precedence than ??. Sadly, they all can’t be in the same precedence group due to right associativity of ??. 2017-02-08 18:11 GMT+03:00 Tony Allevato via

Re: [swift-evolution] SE-0152: Package Manager Tools Version

> On 8. Feb 2017, at 10:49, Will Field-Thompson via swift-evolution > wrote: > > The main package manager I use is CocoaPods and as far as I am aware > CocoaPods doesn't allow you to specify the tools version in the Podfile. This > did cause some (albeit minimal)

Re: [swift-evolution] SE-0152: Package Manager Tools Version

> * What is your evaluation of the proposal? > I fully support the goals of the proposal and have a question about the implementation. * Is the problem being addressed significant enough to warrant a change to > Swift? > Yep. It provides a good way to evolve the API, and putting it in place

Re: [swift-evolution] !? operator for ternary conditional unwrapping

Hi Martin, please see reply inline. On Wed, Feb 8, 2017 at 4:47 PM Martin R wrote: > Isn't that exactly what the nil-coalescing operator ?? does? > > func query(name: String?) -> String { > return "{ param: \(name ?? "null") }" > } > > No, because func

Re: [swift-evolution] Compile-time generic specialization

> On Feb 6, 2017, at 10:06 AM, Douglas Gregor via swift-evolution > wrote: > >> >> On Feb 5, 2017, at 5:36 PM, Abe Schneider via swift-evolution >> > wrote: >> >> Hi Robert, >> >> Exactly. The benefit

Re: [swift-evolution] [swift-build-dev] SE-0152: Package Manager Tools Version

> The review of SE-0152 "Package Manager Tools Version" begins now and runs > through February 13, 2017. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md Hi Martin, Thanks again for your

Re: [swift-evolution] [swift-build-dev] SE-0151: Package Manager Swift Language Compatibility Version

Hello Rick, thanks for the explanation! Am 2017-02-08 17:55, schrieb Rick Ballard: I believe that the reason this was desired is because we expect that package authors may wish to conditionally adopt new Swift 4 language features without breaking their ability to build with Swift 3, using

Re: [swift-evolution] [swift-build-dev] SE-0151: Package Manager Swift Language Compatibility Version

> On Feb 7, 2017, at 11:19 PM, Martin Waitz via swift-build-dev > wrote: > >> The review of SE-0151 “Package Manager Swift Language Compatibility Version" >> begins now and runs through February 13, 2017. The proposal is available >> here: >> >> >>

Re: [swift-evolution] !? operator for ternary conditional unwrapping

I forgot about map :D That solution is more swifty than mine with String(format::). --  Adrian Zubarev Sent with Airmail Am 8. Februar 2017 um 16:12:11, Tony Allevato via swift-evolution (swift-evolution@swift.org) schrieb: What you're asking for is already possible (avoiding the optional

Re: [swift-evolution] !? operator for ternary conditional unwrapping

What you're asking for is already possible (avoiding the optional unwrap) by combining map() on Optional with ??: ``` let name1: String? = "name" print(name1.map { "\"\($0)\"" } ?? "null") // prints "\"name\"" let name2: String? = nil print(name2.map { "\"\($0)\"" } ?? "null") // prints "null"

Re: [swift-evolution] !? operator for ternary conditional unwrapping

If you need a infix operator that traps, here you have one ;) infix operator ?! : NilCoalescingPrecedence func ?! (optional: T?, noreturn: @autoclosure () -> Never) -> T { switch optional { case .some(let value): return value case .none: noreturn() } } let x: Int? = nil

Re: [swift-evolution] SE-0151: Package Manager Swift Language Compatibility Version

Hi, Am 2017-02-08 08:54, schrieb Dimitri Racordon via swift-evolution: I guess allowing a list of versions to be specified is interesting for continuous integration. That would allow people to test their code under all intended supported version. That is a valid use-case, but should be

Re: [swift-evolution] Warning when omitting default case for imported enums

> Allowing the omission of a default case in an exhaustive switch makes the > addition of a new case to the enum a breaking change. Depending on the context, even with a default the change might be breaking — but without giving notice to the framework client! Additionally, it would feel very

Re: [swift-evolution] SE-0152: Package Manager Tools Version

Hi, > The review of SE-0152 "Package Manager Tools Version" begins now and runs > through February 13, 2017. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md From the proposal: > Not changing this