Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

I’m +1 for the proposal. Context, in case it’s useful for anyone: My particular use case for generic subscripts is with my SwiftyUserDefaults library (https://github.com/radex/SwiftyUserDefaults ), which allows users to access user defaults with a

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

Q: Would it be possible to allow some sigil in method names (say, prefix/postfix `=`) without any automatic/magic treatment of these methods? In Ruby, after all, postfix `!` is just allowed in names. It doesn’t have any semantic meaning for the interpreter, it’s just the (strong, well agreed

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

Noo :( I understand and appreciate the rationale, uniformity between declaration and use site being a good thing, but IMHO the proposal just brings unnecessary noise, far outweighing the small benefit of having the symmetry. 1. What I’m worried the most is the “parentheses blindness”. In

Re: [swift-evolution] What about a VBA style with Statement?

ate extension of each just to > have this "with" feature? Don't think so. No — for now, it’s best to use a free function for now. And, like I mentioned, universal conformances could allow this to be easily added to all types — and so I’d focus on pushing *that* proposal. > &g

Re: [swift-evolution] What about a VBA style with Statement?

It can be (more-or-less) solved in library code today: extension NSObjectProtocol { public func with(@noescape fn: Self -> Void) -> Self { fn(self) return self } } This way, you can do, on NSObjects: textLabel.with { $0.textAlignment = .Left $0.textColor

Re: [swift-evolution] Proposal: disallow nil in favor of .None

Pretty sure it has been discussed already. MHO: much of the power of Optionals in Swift is that they’re more than just a .None/.Some(T) enum. They’re tightly integrated into the language. You never say .Some(value) — values are just lifted to optionals automatically. And if we never directly

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

Just FWIW: > ``` > let foo: Foo? = curry(Foo.init) <^> Int(aString) <*> Int(bString) <*> > Int(cString) > ``` > > But I think it is unreasonable to expect all programmers to understand > and master it. So I want the postfix `???` or `|?`. I agree. But I would also say that deserializing from

Re: [swift-evolution] [Proposal] Factory Initializers

Nice! I must admit, my first reaction to this proposal was “uhhh, why complicate initializers even more?”. But then I hit these two roadblocks: 1. I wanted to add an initializer on `NSTimer` extension that returns the (toll-free-bridged) value from CFRunLoopTimerCreateWithHandler. Sadly, this

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

since it's more obviously capturing `self`, and that the > 'self.doSomething' shorthand is a misfeature. > > -Joe > >> On Apr 1, 2016, at 8:09 AM, Radosław Pietruszewski via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Here’s a pattern I

Re: [swift-evolution] Shortcut for creating arrays

FWIW, in Swift 3: “h j c k”.componentsSeparated(by: “”) or “h j c k”.componentsSeparatedByCharacters(in: .whitespace()) which is slightly better. Regarding the proposal, I love Ruby’s %w(foo bar) and other nice shortcuts like that, but short-term I think we have bigger problems in Swift. I

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

> What is your evaluation of the proposal? +1. I like the rule of “don’t make me think”. If I write a piece of code that seems correct to me, why would the compiler “intentionally” stop me from accepting it? Just smooth out this rough edge and remove one scenario in which a compiler error

Re: [swift-evolution] My personal beef with leading-dot syntax

As others noted: * the ability to say .min, .max, .blackColor(), etc is extremely useful. Swift would be a lot worse off if only enum cases got their enum types inferred, and for any other static member of a type I would have type the fully qualified name * the leading dot disambiguates the

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() {

[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] 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] Deprecating Trailing Closures

> I think requring trailing closures to be @noescape would take away some very > compelling use cases for them. In particular, you would lose the ability to > use trailing closures for asynchronous code, like completion functions. I, > for one, would be sad to lose those—they are often some of

Re: [swift-evolution] Deprecating Trailing Closures

I have to admit I’m quite fond of the trailing closure syntax. This is partly because of my earlier experiences with Ruby. But partly I just really found it more readable to see a separation between a regular function call, with just normal parameters passed in, and higher order functions, like

Re: [swift-evolution] Deprecating Trailing Closures

>> I’m not proposing to remove them entirely, in fact your lock example is a >> perfect example of when a trailing closure makes the most sense, as a form >> of customised language feature. But I’m wondering if perhaps cases like >> these should be created using an attribute that specifically

Re: [swift-evolution] allowing to specify optionality with type inference

Could you give us one or two real-world examples where you’d want to do this? I really can’t think of a situation where I would want to assign a non-optional to an optional variable. Even if I transform it later such that it might produce nil, it’s desirable to assign it to two different

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

I think this ability to reorder labeled parameter names is more useful in a dynamic language like Ruby than in Swift, since Ruby doesn’t give my text editor the ability to autocomplete the function signature. If I’m typing the function and its arguments from my head, I’m more likely to forget

Re: [swift-evolution] IUO type, treat nil as normal error, not fatal error

I think it would be an interesting to have an optional type that has throwing semantics on errors (I wonder if the behaviors proposal would allow something like that), but IMHO this should be something else than IUO. IUO is great for when you’re pretty darn sure a thing will never actually be

Re: [swift-evolution] [proposal] Allow trailing closures in 'guard' conditions

+1, it’s a straightforward improvement. It’s a good thing for the language not to surprise me rejecting something that seems completely reasonable. — Radek > On 23 Mar 2016, at 07:03, Chris Lattner via swift-evolution > wrote: > > Hi everyone, > > This is a

Re: [swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

> Also as a brief aside, it’s not super intuitive to me that the syntax for the > catch pattern matching wildcard is > > catch _ > > whereas it is > > default > > for switches. I do believe you can just say `catch`: 4> do { 5. try throwing() 6. } catch let e as E { ... 7. }

Re: [swift-evolution] [Proposal] function "return" optional keyword.

I honestly don’t have a problem with having to say `return` inside functions. That’s not necessarily a -1, but I’m reluctant to say +1 when _even I_ don’t really have the problem with extra verbosity. *However*, as others pointed out, having to type `return` is a bit tiring in the context of a

Re: [swift-evolution] Fluent syntax (replacing void with a useful default return value)

Same as Kevin. I like this pattern, but an implicit behavior of this sort doesn’t seem appropriate. — Radek > On 20 Dec 2015, at 04:05, Kevin Ballard via swift-evolution > wrote: > > This kind of pattern (which I've always considered the "builder pattern") is >

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

> anArray.map(.hasPrefix(“foo”)) I’m against this. Yes, it extends the functionality of the proposal even more and could allow for more closures to be rewritten in this style — but at a severe cost in clarity IMHO. I mean, with `map(.aMethod)`, you’re passing a reference to a method available

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

Sounds like it could be super useful for libraries! How about we drop the quote marks, though? If we have `os(iOS)` and `#available(iOS 9, *)` (in other context), why not `swift(2.2)`? — Radek > On 18 Dec 2015, at 21:22, David Farler via swift-evolution > wrote: >

Re: [swift-evolution] Proposal: Add .times method to Integer type

> But isn’t that more a sign that Swift needs a way to make closures more > useful by adding the possibility of breaking/continueing/returning from > within them rather than a disadvantage of the `times`-syntax itself? Perhaps — there’s a thread, somewhere, with possible solutions to this.