Re: [swift-evolution] [Proposal] Variadics as Attribute

I like this proposal. I was a bit against when the discussion around the removal of variadics arose, but I fee that this proposal takes a good whack at the problem. I have struggled with array vs. variadic arguments for several methods, ending up implementing both overloads and the variadic me

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

It feels so odd especially because of the added emphasis by the core team for argument labels for Swift 3 only to have this passed. What is the pro of not having argument labels in callbacks or functions stored in properties, how does this make for good readability or consistency with instance

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

> * What is your evaluation of the proposal? In general +1, except maybe the change of to isOrderedBefore: by: in sort-related functions. I fear that the new label makes it less clear that the ordering relation is that of strict precedence. It can be particularly confusing for people used

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

For JSONFusion this won't work at all, as the code base is largely Objective-C with lots of Swift-related annotations and depend on Objective-C and Swift ABI details to work. The main trick in JSONFusion is property introspection which don't play nice with Swift yet, and for JSFRemote the main t

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

I’d imagine it would be the same just without the colon and with the braces: enum MyEnum { case IntEnum(Int) case StringEnum(String) } var x=MyEnum.StringEnum("Hello") switch x { case .IntEnum(let x) { print(x) } case .StringEnum(let x) { print(x) } }

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

What would be the proposed syntax for cases with associated values? In general, +1 for simplifying the syntax, but I'm not sure it'd work well, given that enums take on a larger roll in Swift than they do in other languages. Or maybe it'd be fine... I'm just too tired to picture it in my head.

Re: [swift-evolution] [SE-0088] Dispatch API names

Feel free to create one for .read, I already have a radar that covers .after > On Jul 7, 2016, at 7:16 PM, Darren Mo wrote: > > Should I create a bug report for changing `DispatchQueue.after` and > `DispatchSource.read`? > > Darren > >> On Jun 21, 2016, at 7:35 PM, Darren Mo wrote: >> >> On

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> On 7 Jul 2016, at 23:28, John McCall via swift-evolution > wrote: > >> On Jul 7, 2016, at 3:26 PM, Chris Lattner via swift-evolution >> wrote: >>> On Jul 7, 2016, at 10:58 AM, Vladimir.S via swift-evolution >>> wrote: >>> >>> I didn't expect this is allowed(with warning): >>> >>> try pr

Re: [swift-evolution] [SE-0088] Dispatch API names

> On Jun 21, 2016, at 16:46, Darren Mo via swift-evolution > wrote: > > On Jun 21, 2016, at 5:24 PM, Matt Wright > wrote: >>> On Jun 20, 2016, at 7:12 PM, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Mon, Jun 20, 2016 at 9:05 PM, Br

Re: [swift-evolution] [SE-0088] Dispatch API names

Should I create a bug report for changing `DispatchQueue.after` and `DispatchSource.read`? Darren > On Jun 21, 2016, at 7:35 PM, Darren Mo wrote: > > On Jun 21, 2016, at 5:28 PM, Matt Wright > wrote: >>> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution >>> ma

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

On Thu, Jul 7, 2016 at 6:14 PM, Dave Abrahams via swift-evolution wrote: > > on Wed Jul 06 2016, Tim Vermeulen wrote: > >> This is a follow up from this swift-users thread: >> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html >> >> As it stands, RangeReplaceableColle

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

on Thu Jul 07 2016, Haravikk wrote: >> On 7 Jul 2016, at 15:57, Karl via swift-evolution >> wrote: >> >> I believe the idea of RRC is that all you need to implement is the >> empty initialiser and replaceSubrange(), and everything else >> (e.g. Append, insert) is implemented in terms of those

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

on Wed Jul 06 2016, Tim Vermeulen wrote: > This is a follow up from this swift-users thread: > https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html > > As it stands, RangeReplaceableCollection requires an implementation > for init(), which is used in the default implem

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0118: Closure Parameter Names and Labels

on Thu Jul 07 2016, Jordan Rose wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md > ] > > Hi, Dave, Dmitri, Max. Sorry I didn’t make the pre-review commentary > thread. I find I’m still not happy with several of thes

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

Aw. It's really bad that labels are gone for closures at the call site 😢. IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here. I hope I won't come across to many completion(true, false,...) + debugging if someone changes the order of the p

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0118: Closure Parameter Names and Labels

> On Jul 7, 2016, at 5:03 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md > >

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

To be fair and practical with the proposal it does not remove the ability to inherit any of the UIKit classes because all Objective-C classes are imported as "open". Food for thought on inheritance-is-the-only-fix, how have we worked all these years with C libraries like Security, Foundation, Cor

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 5, 2016, at 4:11 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On Jul 7, 2016, at 3:18 AM, Taras Zakharko via swift-evolution > wrote: > > I would also be interested in a clarification on this point from Chris or > someone else from the core team. > > The accepted proposal states that labels are illegal in function types (that > is also what I was ar

Re: [swift-evolution] Dropping Comparable requirement for indices

on Thu Jul 07 2016, Haravikk wrote: >> On 7 Jul 2016, at 02:41, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jul 06 2016, Haravikk wrote: >> > On 6 Jul 2016, at 03:39, Dave Abrahams via swift-evolution wrote: For example, with Comparable indices, you ca

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0118: Closure Parameter Names and Labels

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md ] Hi, Dave, Dmitri, Max. Sorry I didn’t make the pre-review commentary thread. I find I’m still not happy with several of these names, although there are many other improvements

Re: [swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

on Wed Jul 06 2016, Jacob Bandes-Storch wrote: >> * *Remove unsafeAddressOf*. "We are not aware of any real use cases for >> it. If there are any, it should be renamed to unsafeAddress(of:) to follow >> the guidelines." (https://bugs.swift.org/browse/SR-1957 >> rdar://problem/18589289) >> >> > O

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

I agree with everything James has to say here. Making classes non-subclassable by default is not optimal. A lot of fixes for small bugs in UIKit involve using a subclass that overrides at method or slightly modified behaviour as a temporary patch until the issue is fixed at the framework level. Pre

Re: [swift-evolution] Dropping Comparable requirement for indices

on Wed Jul 06 2016, David Sweeris wrote: >> On Jul 6, 2016, at 20:41, Dave Abrahams via swift-evolution >> wrote: >> >> There is no way, AFAIK, to implement important algorithms like rotate >> binarySearch and several others, without having some representation of >> position within a collecti

Re: [swift-evolution] [Discussion][Pre-Proposal] diverges/converges methods for Collection

on Thu Jul 07 2016, Daryle Walker wrote: > I doesn’t seem that anyone noticed the previous post. Here’s an inline copy: > > Implement a mismatch algorithm, equivalent to std::mismatch() in C++ I definitely want this algorithm in the standard library, someday soon. It's out of scope for Swift 3

[swift-evolution] [Accepted with revision] SE-0077 v2: Improved operator declarations

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md The second review of SE-0077, "Improved operator declarations" ran from June 29 ... July 4, 2016. The proposal has been *accepted* with minor revisions. This round of feedback focused on na

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On Jul 6, 2016, at 4:35 PM, David Waite wrote: > > I see two possible approaches: > > 1. A “import Libc” imports the platform libraries, whatever they may be, on > the OS platform you are on. > > 2. The OS platform libraries are divided up, virtually if necessary, to > expose the underlyin

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

On Jul 7, 2016, at 7:46 AM, Karl wrote: > Not only that, but we have compiler fix-its. When there are renaming changes > or argument-label changes, I just filter down my Xcode error list, click each > one, give it a quick eyeball and hit “enter”. I don’t know of other languages > that have had

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> On Jul 7, 2016, at 3:26 PM, Chris Lattner via swift-evolution > wrote: >> On Jul 7, 2016, at 10:58 AM, Vladimir.S via swift-evolution >> wrote: >> >> I didn't expect this is allowed(with warning): >> >> try print("foo") >> >> (Swift Ver. 3.0 (Jun 20, 2016)) >> >> Do we really need to allo

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> On Jul 7, 2016, at 10:58 AM, Vladimir.S via swift-evolution > wrote: > > I didn't expect this is allowed(with warning): > > try print("foo") > > (Swift Ver. 3.0 (Jun 20, 2016)) > > Do we really need to allow 'try' for functions that does not throw exceptions? This seems like totally fair

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution wrote: > I disagree that a stable for over 30 years of every OOP language that I know > is equivalent to lack of care for good library design, but if we want to push > value types by making working with classes harder so be it :P.

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Regards (From mobile) > On Jul 7, 2016, at 6:23 PM, Leonardo Pessoa via swift-evolution > wrote: > > Jean, IMO marking every class as subclassable means the creator does > not care for you to design and develop a great library because s/he is > not caring for the library at all. That is a gro

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 7 Jul 2016, at 22:39, Leonardo Pessoa wrote: > > I think we'd have less effort (and less breaking more > backward compatibility) if we just allow variadic arguments to receive > arrays of its type directly. This proposal doesn't just handle the issue of passing an array however, it also a

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jul 7, 2016, at 11:53 AM, Anton Zhilin via swift-evolution > wrote: > > An important thing to consider is if we really want to break standard library > precedence hierarchy. > If we don't, then the proposal loses significance immediately. > If we do, then we should start discussion of spe

Re: [swift-evolution] [Review #2] SE-0091: Improving operator requirements in protocols

> * What is your evaluation of the proposal? +1. This proposal improves clarity by allowing operator implementations to be declared inside the relevant type (or an extension of it). It also improves implementation as outlined in the proposal. Both are significant steps forward. >

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

I look forward to the final design as i find these precedence groups a great additions. Regards (From mobile) > On Jul 7, 2016, at 9:02 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Jul 7, 2016 at 11:28 AM, Dmitri Gribenko via swift-evolution >> wrote: >> On Thu, Jul 7, 2016 at 9:2

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

It really looks like the process is showing its limits... with so many people, some with knowledge of compiler imposed limitations, most with a laundry list of their favorite features from other languages, and even a few aspiring at finally having anti-gravity boots into the compiler, it seems s

[swift-evolution] Proposal: SwiftPM Target Access Control

Really happy to see this proposal. It will cut build times for packages that use my library significantly. The only point I would bring up is about using a `Bool` for `isPrivate`. This obviously only gives us 2 levels of access control. Something like this would give more flexibility: enum Acc

Re: [swift-evolution] [Proposal] Variadics as Attribute

I believe the alternative can be even simpler if you consider the type of the variadic argument is in fact an array. The different syntax tell the compiler it can relax on demanding an array for that argument and allow multiple comma-separated values of the same declared type. Nothing but the compi

[swift-evolution] Optional comparison operators

These operators cause some potential for confusion: public func <(lhs: T?, rhs: T?) -> Bool public func >(lhs: T?, rhs: T?) -> Bool public func <=(lhs: T?, rhs: T?) -> Bool public func >=(lhs: T?, rhs: T?) -> Bool 1. The meaning of T? < T? is not immediately obvious (Why is nil <

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> Le 7 juil. 2016 à 18:23, Leonardo Pessoa via swift-evolution > a écrit : > > Jean, IMO marking every class as subclassable means the creator does > not care for you to design and develop a great library because s/he is > not caring for the library at all. I right now have to go through the >

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

Don’t get me wrong, I’m not a huge fan of having extra punctuation around, but as a matter of syntactic consistency, it seems the right thing to do. It’s adding a single character (less than the `do` alternative that some are suggesting. It seems like the arguments against it are the same as

[swift-evolution] [Proposal] Variadics as Attribute

Posted a new proposal, feedback appreciated: https://github.com/Haravikk/swift-evolution/blob/2743411af02e3ac6761fbdd780ede1af4cc34ee7/proposals/-variadics-as-attribute.md One talking point raised already is the correct location for the attribute (parameter or type); I'm undecided personally

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

> On Jul 7, 2016, at 2:05 PM, Haravikk via swift-evolution > wrote: > > There's also the issue of scope; you can fall through from a case, so > technically speaking the only scope may be the switch itself, as you could > fall through every single case and thus visit everything on the way down.

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

You can have this now: switch x { case 0: { print(0) }() case 1: { print(1) }() case 2: { print(2) }() default: { print("other²) }() } However it isn¹t quite the same. Case with a colon has far too many parallels in other very common languages IMHO. I am not sure being consistent is always a mu

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

> On 7 Jul 2016, at 21:07, G B via swift-evolution > wrote: > > It has always seemed odd to me that `case`s use a colon as a delimiter rather > than curly braces like everything else. Is there a reason for this other > than the legacy of C-like languages? > > If I wanted to write a series

Re: [swift-evolution] [Discussion][Pre-Proposal] diverges/converges methods for Collection (was: Proposal to copy C++'s mismatch)

Folks are focusing on Swift 3 and non-critical additive things aren't going to get attention. It is best to avoid discussion of non-critical additive proposals until the focus returns to future looking (e.g post Swift 3). On Thu, Jul 7, 2016 at 1:48 PM Daryle Walker via swift-evolution < swift-evol

[swift-evolution] [Discussion][Pre-Proposal] diverges/converges methods for Collection (was: Proposal to copy C++'s mismatch)

I doesn’t seem that anyone noticed the previous post. Here’s an inline copy: Implement a mismatch algorithm, equivalent to std::mismatch() in C++ Proposal: SE- Author: Daryle Walker Status: Awaiting review Re

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

But in general, if I use enums, I have more cases than I normally would have of if-else statements. I try not to have many if-else chains but I generally have 2+ cases which would result in more braces than my typical if-else > On Jul 7, 2016, at 4:41 PM, G B via swift-evolution > wrote: > >

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

I always wrap my case blocks in curly braces. Personally, I agree with G.B. that the switch syntax seems inconsistent at best. While there are labels and limited form of goto in Swift, case labels don’t act anything like that. I’d prefer symmetry with if by having obligatory braces. — Taras

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

On Thu, Jul 7, 2016 at 3:41 PM, Roth Michaels via swift-evolution < swift-evolution@swift.org> wrote: > On Thu, Jul 07 2016 at 04:33:17 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > Fallthrough ceases to make much sense with braces, and it is a handy > > feature of sw

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

Braces don’t preclude using `break` or `continue`, why would they preclude `fallthrough`? > On Jul 7, 2016, at 13:33 , Xiaodi Wu via swift-evolution > wrote: > > Fallthrough ceases to make much sense with braces, and it is a handy feature > of switch statements every so often. > On Thu, Jul

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

On Thu, Jul 07 2016 at 04:33:17 PM, Xiaodi Wu via swift-evolution wrote: > Fallthrough ceases to make much sense with braces, and it is a handy > feature of switch statements every so often. > I assume you mean "Fallthrough cases make much 'less' sense with braces"? -- Roth Michaels r...@rothmic

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

The same can be said for if/else constructs though— all those braces get heavy if they’re all wrapping one line each. Python does away with the braces and relies on indentation, but Swift has explicitly stated that it will not follow that path— yet case statements seem an exception. It’s a col

Re: [swift-evolution] [Discussion] Parentheses

I guess you are suggesting to: 1. Add single-element tuples to the language (not convertible to "plain" types) 2. Make all otherwise unnecessary parentheses signify single-element tuples In my first answer, I mentioned Haskell, because it treats types and variables in pretty much the same way. In

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

Fallthrough ceases to make much sense with braces, and it is a handy feature of switch statements every so often. On Thu, Jul 7, 2016 at 15:31 Roth Michaels via swift-evolution < swift-evolution@swift.org> wrote: > On Thu, Jul 07 2016 at 04:07:06 PM, G B via swift-evolution < > swift-evolution@swi

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

On Thu, Jul 07 2016 at 04:07:06 PM, G B via swift-evolution wrote: > I feel like this would be more consistent with the rest of the syntax: > > switch x { > case 0 { print(0) } > case 1 { print(1) } > case 2 { print(2) } > default { print("other”) } > } > > The colon syntax evokes a label, but th

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

When each case only takes up one line, it may look nice and concise. But what happens in the common case when your case takes up more lines and you indent your braces? > switch x { > case 0 { print(0) } > case 1 { print(1) } > case 2 { print(2) } > default { print("other”) } > } switch x { case

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

A few questions: 1. What is universal lookup? How is this different than the compiler having to search a crowded namespace? I'm really trying to understand how this is making it easier for the type checker. 2. If operators are a special case, why not replace static/class func with an "operato

[swift-evolution] [Idea] Wrap switch cases in curly braces

It has always seemed odd to me that `case`s use a colon as a delimiter rather than curly braces like everything else. Is there a reason for this other than the legacy of C-like languages? If I wanted to write a series of branching `if` \ `else` statements I would do it like so: if x==0

Re: [swift-evolution] [Review #2] SE-0091: Improving operator requirements in protocols

> * What is your evaluation of the proposal? +1. This is a good solution. Would like to see the class thing fixed, but that can be another proposal. > * Is the problem being addressed significant enough to warrant a change to > Swift? Yes. Having to declare these inside protocols, but impleme

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

Hi Thanks for the proposal, looks very nice. The Package.swift manifest files is very string typed already, (package name, url, target names, etc) and and think that is ok in our case. We can make a type for external dependency that would have 2 properties: package and target. That could help e

Re: [swift-evolution] [Review #2] SE-0091: Improving operator requirements in protocols

* What is your evaluation of the proposal? +1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes * Does this proposal fit well with the feel and direction of Swift? Yes * If you have used other languages or libraries with a similar

Re: [swift-evolution] [Discussion] Parentheses

Also, regarding the special case of single element tuples, ie Int being the same type as (Int) and Int))): I'm wondering if that can be viewed as an irregularity baked in at the foundation of the system (parenthesized expressions), sending ripples of perhaps needless complexity through the rest

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> On 7 Jul 2016, at 19:41, David Sweeris via swift-evolution > wrote: > > >> On Jul 7, 2016, at 12:58, Vladimir.S via swift-evolution >> wrote: >> >> I didn't expect this is allowed(with warning): >> >> try print("foo") >> >> (Swift Ver. 3.0 (Jun 20, 2016)) >> >> Do we really need to all

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> On 7 Jul 2016, at 15:57, Karl via swift-evolution > wrote: > > I believe the idea of RRC is that all you need to implement is the empty > initialiser and replaceSubrange(), and everything else (e.g. Append, insert) > is implemented in terms of those. Even the initialiser which takes existin

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

On Thu, Jul 7, 2016 at 11:28 AM, Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote: > On Thu, Jul 7, 2016 at 9:27 AM, John McCall wrote: > > On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > > wrote: > >> Proposal link: > >> > >> > >> > https://github.com/app

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

An important thing to consider is if we really want to break standard library precedence hierarchy. If we don't, then the proposal loses significance immediately. If we do, then we should start discussion of specific changes right after this one. I'm fine with NilCoalescingPrecedence, because Coal

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

On Thu, Jul 7, 2016 at 11:37 AM Daniel Resnick via swift-evolution < swift-evolution@swift.org> wrote: > What is your evaluation of the proposal? >> > +1 > > >> Is the problem being addressed significant enough to warrant a change to >> Swift? >> > Yes, the current situation of defining a protocol

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

Hi, Thanks for feedback. I agree that specifying external dependencies with targets would be great. I think the only thing issue is to figure out is how to specify them. Some thoughts: Note: Currently target name has to be unique across all the targets in the package (including its dependencies).

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> On Jul 7, 2016, at 12:58, Vladimir.S via swift-evolution > wrote: > > I didn't expect this is allowed(with warning): > > try print("foo") > > (Swift Ver. 3.0 (Jun 20, 2016)) > > Do we really need to allow 'try' for functions that does not throw exceptions? What's the harm? - Dave Sweeris

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

> > What is your evaluation of the proposal? > +1 > Is the problem being addressed significant enough to warrant a change to > Swift? > Yes, the current situation of defining a protocol required operator function globally is potentially confusing and feels inconsistent. > Does this proposal fit

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

Goffredo, sorry if it felt offensive. It was not my intention. I've dealt with so many different libraries where, as many already pointed out here, has to rely on "fixing" the library themselves. This is not what a library was supposed to be and I might have left a few of my bad experiences spea

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

> On Jul 7, 2016, at 8:46 AM, Karl via swift-evolution > wrote: > It’s nice that you like Swift 3.0 so much, but it still has holes - there are > plans in the generics manifesto for instance which are basically just limited > by implementation. We don’t have a stable ABI. Reflection is still f

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

> * What is your evaluation of the proposal? +1. Improved type checker performance for operator overloads alone is enough for me. Improved locality of implementation is the cherry on top. > * Is the problem being addressed significant enough to warrant a change > to Swift? Absolu

[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> * What is your evaluation of the proposal? I’m on board with solving the problems outlined here. In particular, continuing to make Swift safe and fast by default and extending access and features as needed. And I am mostly on board with the solution proposed here. I have 2 big concerns: 1) U

[swift-evolution] [Discussion] "try" for function that does not throw

I didn't expect this is allowed(with warning): try print("foo") (Swift Ver. 3.0 (Jun 20, 2016)) Do we really need to allow 'try' for functions that does not throw exceptions? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swi

[swift-evolution] [Review #2] SE-0091: Improving operator requirements in protocols

Hello Swift community, The second review of "SE-0091: Improving operator requirements in protocols" begins now and runs through July 12. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md Reviews are a

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> On 7 Jul 2016, at 19:10, Karl wrote: > > >> On 7 Jul 2016, at 17:19, Tim Vermeulen > > wrote: >> >>> >>> On 7 Jul 2016, at 16:57, Karl >> > wrote: >>> >>> On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution mailto:swif

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> On 7 Jul 2016, at 17:19, Tim Vermeulen wrote: > >> >> On 7 Jul 2016, at 16:57, Karl wrote: >> >> >>> On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution >>> wrote: >>> >>> This is a follow up from this swift-users thread: >>> https://lists.swift.org/pipermail/swift-users/Week-of

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

I disagree that a stable for over 30 years of every OOP language that I know is equivalent to lack of care for good library design, but if we want to push value types by making working with classes harder so be it :P. Seriously though > Mine is the opinion of a library-maker, > yours of the us

Re: [swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

> On Jul 7, 2016, at 08:58, Dmitri Gribenko wrote: > > On Wed, Jul 6, 2016 at 9:57 PM, Charlie Monroe via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> >> On Jul 7, 2016, at 12:46 AM, Jordan Rose via swift-evolution >> wrote: >> >> >> On Jul 6, 2016, at 11:03, Jacob Bandes-St

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

On Thu, Jul 7, 2016 at 9:27 AM, John McCall wrote: > On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > wrote: >> Proposal link: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > Dave, Max and I discussed SE-0077 and reviewed th

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > wrote: > > Proposal link: > > > > https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > > > >

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Jean, IMO marking every class as subclassable means the creator does not care for you to design and develop a great library because s/he is not caring for the library at all. I right now have to go through the burdensome activity of marking too many classes/methods as final to prevent misuse of my

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md Dave, Max and I discussed SE-0077 and reviewed the names of precedence groups. Here's our recommendation. In general, we think some names don't read well and have some ambiguities, for

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

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

[swift-evolution] [Idea] Deferable type for swift and smaller defer scope

I have been using defer for very happy. It’ like with keyword on python, using easily for needs closing context like NSFileHandle. anyway defer is very useful statement for function scope. However, I thinking now, What if i can use more small defer. below, that’s codes of idea. // firstbly, cre

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

* What is your evaluation of the proposal? Strong -1 too. I can’t count the number of times it save my hours tone able to override arbitrary classes and methods. Sometimes to simply add log point to understand how the API work. Other times to workaround bugs in the library. Or even to extend

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

Hello Ankit, Thanks a lot for taking the initiative for this! This looks like a great start. I think what we will eventually want to do is to let package authors express the "role" of each target, which would then allow expression of such things as build-time vs run-time dependencies. For exa

Re: [swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

On Wed, Jul 6, 2016 at 9:57 PM, Charlie Monroe via swift-evolution wrote: > > On Jul 7, 2016, at 12:46 AM, Jordan Rose via swift-evolution > wrote: > > > On Jul 6, 2016, at 11:03, Jacob Bandes-Storch via swift-evolution > wrote: > > >> * Remove unsafeAddressOf. "We are not aware of any real use

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0113: Add integral rounding functions to FloatingPoint

Small correction: actually the no-argument cases don't need to be declared as requirements in the protocol. Sent from my moss-covered three-handled family gradunza > On Jul 6, 2016, at 8:46 PM, Chris Lattner wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/pro

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

On Jul 5, 2016, at 5:10 PM, Chris Lattner via swift-evolution wrote: > > Hello Swift community, > > The review of "SE-0118: Closure Parameter Names and Labels" begins now and > runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/mas

Re: [swift-evolution] Proposal: SwiftPM Target Access Control

Happy to see this in motion! I wrote up a jira a while back for this: https://bugs.swift.org/browse/SR-859 +1 for the solution. I prefer the target-based system over source files. > On Jul 7, 2016, at 5:26 AM, Ankit Agarwal via swift-evolution > wrote: > > Hi swift packagers, > > I am propos

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> On 7 Jul 2016, at 16:57, Karl wrote: > > >> On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution >> wrote: >> >> This is a follow up from this swift-users thread: >> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html >> >> As it stands, RangeReplaceableC

Re: [swift-evolution] [Pre-proposal] Fix function type grammar

On 07.07.2016 17:29, Anton Zhilin via swift-evolution wrote: > Questions about that proposal are often risen on the list. > Some think that we will still be able to supply () argument > to () -> T functions. > > To clear that up completely, I suggest adding this grammar change

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> On 7 Jul 2016, at 16:57, Karl wrote: > > >> On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution >> wrote: >> >> This is a follow up from this swift-users thread: >> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html >> >> As it stands, RangeReplaceableC

Re: [swift-evolution] [Discussion] Parentheses

As previously mentioned, I was talking about using those symbols only as a thinking-tool to possibly simplify language design, making the "real" differences and similarities easier to see while thinking about the design. The final syntax could perhaps still use normal parentheses for all these part

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> On 7 Jul 2016, at 07:50, Tim Vermeulen via swift-evolution > wrote: > > This is a follow up from this swift-users thread: > https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html > > As it stands, RangeReplaceableCollection requires an implementation for > init(), w

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

> On 6 Jul 2016, at 20:28, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi there > > From the perspective from many active programmers > that use Swift (not objective C anymore) I am not > very happy by having to change > program source all the time: > > Therefore after Swift 3.0

  1   2   >