Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

[Alex Migicovsky via swift-evolution]

I think instead of an attribute I’d prefer rules that allow trailing closures 
at call sites. The most straightforward solution would be to only allow using 
trailing closures at the call site if the invoked function has a single closure 
that’s the last parameter. I think the only unfortunate aspect of that is it’s 
an implicit rule which makes it harder for new devs to learn (and experienced 
devs to remember!).

- Alex

> On Jan 4, 2016, at 4:45 AM, QQ Mail via swift-evolution 
>  wrote:
> 
> Hi, All: 
>   trailing closure is good for most cases, but sometimes it is also make 
> code unclear, for example: 
>   
> UIView.animateWithDuration(0.3, animations: { () -> Void in
> // animation code here
> }) { (Bool) -> Void in
> // completion code here
> }
> 
> the label been removed and the code also not aligned well. 
> I would like to write like this: 
> 
> UIView.animateWithDuration(0.3,
> 
> animations: { () -> Void in
> // animation code here
> },
> completion: { Bool -> Void in
> // completion code here
> }
> )
> 
> It is possible, just every time you have to write it manually. It’s a little 
> wast.
> So I have a thought, since we already know this function is not well suit for 
> trailing 
> closure, can we add a attribute to disable it, for example: 
> 
> extension UIView {
> 
> @disable_trailing_closure
> public static func animateWithDuration(duration:NSTimeInterval, 
> animations:()->Void, completion:()->Void) {
> // implementations ...
> }
> }
> 
> I also found another one have issue for this too. link: 
> http://www.natashatherobot.com/swift-trailing-closure-syntax/ 
> 
> what do you think?
> 
> Best Regards
> 
> ChenYungui
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Alex Migicovsky via swift-evolution]

> * What is your evaluation of the proposal?

I think the proposal is great. The only thing I’d prefer is to use `associated` 
over `associatedtype`.

`associated` has always felt better to me over `associatedtype`. It was 
mentioned in one of the original proposals as the keyword that was initially 
most well received as well—I think this is because it just feels right, which 
is a good indicator even though it doesn’t seem scientific :-)

One downside mentioned is that `associated` is more vague than 
`associatedtype`, but there’s a reason why we don’t have `protocoltype`, 
`classtype`, etc as keywords over `protocol` and `class`. I think the 
convention of having associated type names start with an uppercase letter makes 
it clear that what follows `associated` is a type (or will be a concrete type).

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes, I’ve seen many developers be confused by the difference between defining a 
typealias inside a protocol declaration vs outside.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I’ve been paying attention to the thread and have thought about why I like 
`associated` over `associatedtype` since the start of the thread.

- Alex
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Alex Migicovsky via swift-evolution]

> On Dec 28, 2015, at 10:24 AM, Stephen Celis <stephen.ce...@gmail.com> wrote:
> 
>> On Dec 28, 2015, at 11:47 AM, Alex Migicovsky via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On Dec 27, 2015, at 1:32 PM, Joe Groff via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Some more things to consider:
>>> 
>>> - Our naming conventions encourage the first parameter to most methods to 
>>> be unlabeled, so unlabeled parameters come up a lot. I don't think there's 
>>> a grammatical requirement for an identifier before each colon; maybe we can 
>>> leave out the underscore and use `foo(:bar:)` instead of `foo(_:bar:)` to 
>>> refer to unlabeled arguments.
>> 
>> At first glance it seems like we can remove the parens altogether if we went 
>> with this approach. Could instance.`foo:bar:` work (instance.`foo` in the 
>> no-arg case)? I’m not sure how removing parens would work for inits and 
>> subscripts though.
> 
> While the conventions encourage the first parameter to be unlabeled, it 
> doesn't enforce it (and there are exceptions in the standard library, like 
> `removeAll(keepCapacity:)`, as well as `stride(to:…)` and `stride(through:…)`.
> 
> Stephen

Ah right, great point :-)

- Alex___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution