Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> > > class UITableView { > ... > private func addRow(at indexPath: NSIndexPath) { > ... > cell.size.height = delegate?.tableView(self, > heightForRowAtIndexPath: indexPath) ?? rowHeight >

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

-1 I hope that default implementations living in the protocol will address this. I would even prefer to move in 'the other direction' and have optional methods on protocols come into swift as default implementations. TJ On Sat, Apr 2, 2016 at 6:07 AM, Brent Royal-Gordon via swift-evolution <

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> Protocol requirements with default (no-op) implementations already satisfy > that design goal, no? Kind of. If I may steelman* optional members for a moment... In cases where a default implementation would do, the default implementation will usually also be the behavior you want for a nil

Re: [swift-evolution] [Review] SE-0057: Importing Objective-C Lightweight Generics

> * What is your evaluation of the proposal? Generally I like the proposal and I think it helps solidify the bridging story. On casting: In our coding standards, any use of “as!” warrants much higher scrutiny (any use of try! or IUOs gets the same treatment). For a type that opts-in to

Re: [swift-evolution] [Pitch] Custom Namespaces

Yes something in this space might be useful, but, and this is a significant but, we do have modules and files to break code into. So it wouldn't be a top priority. On Wednesday, 30 March 2016, Niels Andriesse via swift-evolution < swift-evolution@swift.org> wrote: > At the moment, it's not

Re: [swift-evolution] Feature proposal: Range operator with step

No I would not be surprised by a limit based on Int provided that: 1. It was articulated in the documentation 2. The error occurred when the Range/stride was created 3. The error message stated that there were too many steps and what the step limit was What I don't think would be

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

+1 with the same evaluation as Sebastian Hagedorn On Friday, 1 April 2016, Sebastian Hagedorn 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

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

+1 Same as Matthew Johnson said On Friday, 1 April 2016, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > >- What is your evaluation of the proposal? > > +1. The current behavior is surprising in a somewhat confusing way. > > >- Is the problem being addressed

Re: [swift-evolution] SE-0025: Scoped Access Level, next

Check out the `testable` attribute: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Attributes.html#//apple_ref/doc/uid/TP40014097-CH35-ID347 Lots of examples if you type `swift testable` into your favorite search engine. On Fri, Apr 1, 2016 at

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

> On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution > wrote: > > Douglas Gregor via swift-evolution > wrote: >> Hello Swift community, >> >> The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance >> Member

Re: [swift-evolution] SE-0025: Scoped Access Level, next

I’m fairly sure what you are asking for already exists with @testable: https://www.natashatherobot.com/swift-2-xcode-7-unit-testing-access/ > On 01 Apr 2016, at 23:04, John Heerema via swift-evolution > wrote: > > I’m a fan of test-driven development. > I use it

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

I would prefer the conditional statements to treat trailing closures consistently, rather than allow this minor but inconsistent convenience. I don't think this needs changing. I read the proposal and followed the list discussion. ___ swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

> What is your evaluation of the proposal? -1 I admire the goal of making trailing closures usably in guard, but I do not like the inconsistency between guard and if. I also never liked the inconsistency with the else keyword in guard. Bother those reasons means that I’m worried that this will

Re: [swift-evolution] SE-0025: Scoped Access Level (DECISION)

Great! Glad that we have a decision. On Fri, Apr 1, 2016 at 4:34 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Mar 30, 2016, at 9:22 PM, Chris Lattner wrote: > > > > I’ve seen a number of concerns on this list about moduleprivate, and how > it

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Douglas Gregor via swift-evolution wrote: > Hello Swift community, > > The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance > Member Implementations" begins now and runs throughApril 5, 2016. The > proposal is available here: > >

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

> My apologies if this was previously discussed. Was there ever a reason given > for not using operators for set combiners? That is, | & - ^ for union, > intersection, subtracting, and symmetricDifference, and |= &= -= ^= for the > mutating versions. With a few exceptions (like `+` for

[swift-evolution] SE-0025: Scoped Access Level, next

I'm a fan of test-driven development. I use it myself, and teach it to students and colleagues. One of the nice things about Swift 1.0 was that it was easy to write module tests. When access controls were introduced into Swift, I found that many functions and objects that had no genuine need

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Em sex, 1 de abr de 2016 às 01:31, Ilya Belenkiy via swift-evolution < swift-evolution@swift.org> escreveu: > With these names we lose consistency. The current scheme makes it very > clear that each next level is a subset of the previous level. With > "internal", fileprivate looks out of place. >

[swift-evolution] SE-0059: Update API Naming - leading dot prefix for enum instances.

If I may, I would like to express support for NOT making this change. One of Swift's really nice features is its ability to remove unnecessary syntactic cruft in cases where the context makes it possible for the compiler to infer a type or name. It's one of Swift's best features, and I would

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

> What is your evaluation of the proposal? +1. In addition to bringing greater consistency, requiring the leading dot will make it easier to grep one's codebase for enum case values. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. > Does this proposal

Re: [swift-evolution] Catching NSException

Hi Jon, I ran into a similar situation and needed a way to not only catch NSExceptions from Swift, but throw them as well. If it would he useful to you, it's part of the open-source CleanroomBridging module, which is intended to ease a few Swift/ObjC interoperability issues. The header file

Re: [swift-evolution] Question about heterogeneous collections

Ugh, sorry to spam the list like this (and also sorry I broke the threading…) Dave’s hint to use “when Element == MyProtocol” (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013922.html) worked great for the example that I posted but falls down in some other cases. I

Re: [swift-evolution] Enable omitting `let` for constant declarations

Did you mean the thread "Mutability inference"? What I talked about is different from it. I am against the idea of "Mutability inference". What I talked about is just enabling to omit `let` for constant declarations. It distinguishes the following three explicitly. > - assignment > - declaration

Re: [swift-evolution] Question about heterogeneous collections

I should double check before I post. That Stack Overflow question has the same answer Dave posted earlier in this thread, which is more correct - it just has fewer votes, and isn’t marked as the accepted answer. Sorry! > On Apr 1, 2016, at 2:32 PM, Jason Sadler wrote: >

Re: [swift-evolution] Question about heterogeneous collections

Thanks everyone for your answers - this has helped p a lot. However because I’m not a language design pro, I’m a little unclear still on what the difference is between `Element == MyProtocol` and `Element: MyProtocol`. Obviously the latter is “Element conforms to MyProtocol” but I don’t know

Re: [swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

> On Mar 31, 2016, at 11:43 PM, Fabian Ehrentraud > wrote: > > Great to hear IUOs losing ground :-) > > Might adding additional compiler warnings as described in SR-104 accompany > the implementation of this proposal well? >

Re: [swift-evolution] A shortcut for weakly referencing functions

As we briefly discussed on Twitter, I feel like Swift already has too much closure syntax as it is. { [unowned self] self.doSomething($0) } is definitely more text than self.doSomething, but it's clear what it's doing. "self.doSomething" method applications are also the only place where we

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

In terms of alternatives to fileprivate, I just want to chime in to say that "filewide" seems to be a term that people seem to reach for in describing this scope, based on a quick Google search. It's readable, IMO, and definitely an adjective, it breaks no new ground in terms of coining a new

Re: [swift-evolution] [Draft] SwiftPM: Adding development package as a dependency

On Fri, Apr 1, 2016 at 10:45 PM, Max Howell wrote: > I’m wondering if the dev package should be inside Packages in some manner, > perhaps as a symlink. > > Otherwise when you looks inside Packages you don't see all your > dependencies. > Since as per current design dev

Re: [swift-evolution] [Draft] SwiftPM: Adding development package as a dependency

I’m wondering if the dev package should be inside Packages in some manner, perhaps as a symlink. Otherwise when you looks inside Packages you don't see all your dependencies. Also since this is related to the lockfile work, I’d like to wait until that is done, probably we could use very

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Good point. That would obviously restrict the choice for naming the methods in such a protocol, but since we are talking about new protocols that would not be an impediment. It might result in non-optimal method names, of course. -Thorsten > Am 31.03.2016 um 18:37 schrieb Rob Mayoff via

Re: [swift-evolution] A shortcut for weakly referencing functions

>> Here’s a pattern I find myself doing quite often: >> >> 1> class Child { >> 2. var onSomeEvent: () -> Void = { } >> 3. } >> 4> class Parent { >> 5. let child = Child() >> 6. init() { >> 7. child.onSomeEvent = doSomething >> 8. } >> 9. func doSomething() {

Re: [swift-evolution] SetAlgebra naming update

> Am 31.03.2016 um 19:53 schrieb Dave Abrahams : > > >> on Thu Mar 31 2016, Thorsten Seitz wrote: >> >> Am 30. März 2016 um 17:48 schrieb Dave Abrahams : >> >>on Wed Mar 30 2016, Thorsten Seitz wrote: >> >>Am 30.03.2016 um

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

How about: notprivateatall notveryprivate mostlyprivate stayout!!!private Sorry. April fools.. :-) > On Apr 1, 2016, at 8:00 AM, Ross O'Brien via swift-evolution > wrote: > > "or within my whole program (external)". That caused a double-take on its own. > >

Re: [swift-evolution] A shortcut for weakly referencing functions

Responses inline! Sincerely,   Zachary Waldowski   z...@waldowski.me On Fri, Apr 1, 2016, at 11:09 AM, Radosław Pietruszewski via swift-evolution wrote: > Here’s a pattern I find myself doing quite often: > > 1> class Child { > 2. var onSomeEvent: () -> Void = { } > 3. } > 4> class

Re: [swift-evolution] Question about heterogeneous collections

See inline > Am 31.03.2016 um 20:14 schrieb Dave Abrahams via swift-evolution > : > > >> on Tue Mar 29 2016, Jason Sadler wrote: >> >> Hi folks, >> >> I have an issue with using a heterogeneous array of objects conforming >> to a

[swift-evolution] A shortcut for weakly referencing functions

Here’s a pattern I find myself doing quite often: 1> class Child { 2. var onSomeEvent: () -> Void = { } 3. } 4> class Parent { 5. let child = Child() 6. init() { 7. child.onSomeEvent = doSomething 8. } 9. func doSomething() { 10. } 11. } I have

Re: [swift-evolution] Deprecating Trailing Closures

> On 31 Mar 2016, at 16:08, Erica Sadun wrote: > >> >> On Mar 31, 2016, at 5:56 AM, Radosław Pietruszewski > > wrote: >>> I follow the "Rule of Kevin", which is not language enforced. Parens around >>> functional >>>

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

"or within my whole program (external)". That caused a double-take on its own. external things are not within, they are outside. 'external' could be a replacement term for 'public', not for 'internal'. This may well be a subjective thing, but I don't think in files, I think in modules because

Re: [swift-evolution] Enable omitting `let` for constant declarations

I can’t easily find it, but there’s been at least one thread proposing this exact thing, and there was very little interest in the proposal. TL;DR is that Swift *by design* wants to make the difference between these three concepts: - assignment - declaration of a constant - declaration of a

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

A new type is implicitly internal to a module. Implicitly specifying it as 'external' is just plain confusing. On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > I know this is kind of winding down, and there seems to be a kind of > begrudging

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

>> None taken. However, most of the delegate concept of UIKit relies heavily on >> this "nonsensical" requirement. It is impossible for someone to implement a >> control in swift which is "in the spirit" of UIKit, meaning the control has >> a delegate, with several methods that share the same

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

> > What is your evaluation of the proposal? Anything that increases consistency is good. > 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I know this is kind of winding down, and there seems to be a kind of begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue), but I still really don’t like it so I’m going to toss out my current favorite configuration and try to stop caring and defer to the core team to make an

[swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

+1 for this proposal. Seems very reasonable to reduce confusion with very little overhead. It would enforce what people should already be doing. ___ swift-evolution mailing list swift-evolution@swift.org

[swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

+1 for this proposal. The resulting code would be clear enough and brings benefit. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> I’ve seen a number of concerns on this list about moduleprivate, and how it > penalizes folks who want to explicitly write their access control. I’ve come > to think that there is yes-another possible path forward here (which I > haven’t seen mentioned so far): > > public > internal >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0056: Allow trailing closures in `guard` conditions

> 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 feature, how do > you

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

> What is your evaluation of the proposal? +1 > Is the problem being addressed significant enough to warrant a change to > Swift? Yes, it is pretty confusing, especialyl for beginners. I can’t see any benefit in the discarded syntax (without dot). > Does this proposal fit well with the feel

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

Brent Royal-Gordon via swift-evolution writes: > A possible mistake in the proposal: Fixed, thanks! -Dave ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

Great to hear IUOs losing ground :-) Might adding additional compiler warnings as described in SR-104 accompany the implementation of this proposal well? https://bugs.swift.org/browse/SR-104 Fabian On 31.03.2016, at 18:43, Chris Lattner via swift-evolution