Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

[Víctor Pimentel Rodríguez via swift-evolution]

On Wed, Aug 2, 2017 at 1:09 PM, Gor Gyolchanyan via swift-evolution <
swift-evolution@swift.org> wrote:
>
>  and if you have a huge entity, it doesn't get better just because you
> split it and hide its complexity.
>
>
> Splitting and hiding complexity is by far the only reasonable way of
> dealing with huge entities. If the entity gains too much responsibility,
> it's probably a good idea to split it into several smaller entities. If the
> entity contains a large amount of accidental complexity that solely serves
> the purpose of enabling a select set of intended features, then it's
> probably a good idea to hide the accidental complexity away from users of
> the entity.
>
> In fact, that's exactly why I always wished that protocols could get
> private requirements that are there solely for use in protocol extensions
> and are otherwise hidden from existence. I haven't talked about this in
> detail because I don't see a reasonable way of implementing it yet.
>

+1, although most times I wanted this because of the impossibility of
defining stored attributes in protocol extensions, let alone private stored
attributes.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

[Víctor Pimentel Rodríguez via swift-evolution]

On Wed, Aug 2, 2017 at 12:26 PM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> That would work as well, but it has the downside of forcing a potentially
> huge number of methods to be implemented in a single place, reducing the
> readability as opposed to packing them into semantically related groups in
> the form of extensions.
>
> I really don't get why people are so obsessed with same-file extensions:
> They are recommended in style guides, influencers blog about them, and
> they motivated a ridiculous complex change in the access rights system. Yet
> I haven't seen any evidence that they offer real benefit.
> Extensions are great for adding useful helpers to existing types, and
> still allow you to selectively expose details of your own classes — but
> most people seem to ignore those options and focus on something can be done
> better with plain old comments.
> [sorry for the rant — but I think a critical look at extensions is long
> overdue: I rarely see someone questioning their role, so basically, we are
> making important decisions based on pure superstition]
>
> A protocol itself is already a vehicle to group related methods, and if
> you have a huge entity, it doesn't get better just because you split it and
> hide its complexity.
>

In my organization we use same file extensions to group methods by
visibility (and also by protocol conformance), so instead of:

public class MyClass {
public func method1() {}
public func method2() {}
public func method3() {}
public func method4() {}
public func method5() {}
private func method6() {}
private func method7() {}
private func method8() {}
private func method9() {}
}

We write:

public class MyClass {
}

public extension MyClass {
func method1() {}
func method2() {}
func method3() {}
func method4() {}
func method5() {}
}

private extension MyClass {
func method6() {}
func method7() {}
func method8() {}
func method9() {}
}

The main reason is not having to repeat the visibility modifier, although
this brings several other advantages and makes our code style more
consistent and easier to follow:

- It forces us to put the private methods at the end of the file, and
that's good because they are implementation details and thus not the first
thing a reader should see. You could do this with comments, but the
syntactic separation seems stronger.
- It makes trivial switching the visibility of the "public methods". For
example we extracted some frameworks from our app and thanks to this
organization it was trivial to change every internal definition to public
ones.
- It also works with other modifiers like @objc.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Víctor Pimentel Rodríguez via swift-evolution]

On Fri, Jun 30, 2017 at 7:24 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Using an operator to provide feedback on the context of a failed unwrap
> has become a commonly implemented approach in the Swift developer
> Community. What are your thoughts about adopting this widely-used operator
> into the standard library?
>
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
>
> Details here:  https://gist.github.com/erica/
> 423e4b1c63b95c4c90338cdff4939a9b
>
> Thank you for your thoughtful feedback, -- E
>
>
> Finally found a few minutes to read this thread.
>
> I'm a big fan of the `Never`-based approach. (I was before, but I am more
> so now.) Here are the points I can see in its favor:
>
> 1. It is extremely clear about what's happening—`!!` is another random
> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are
> fairly self-explanatory, and `??` is something you might already be using.
>
> 2. It allows you to control the optimization behavior by using
> `fatalError`, `preconditionFailure`, or `assertionFailure` as desired.
>
> 3. If we later change `throw` from being a statement to being a
> `Never`-returning expression, you could use `throw` on the right-hand side
> of `??`.
>
> 4. It supports other `Never`-returning operations, like `abort()` or
> `exit(_:)` or your custom `usage()` function, on the right side of `??`.
>
> 5. It supports file-and-line error reporting without having to add any new
> features; `!!` could not do this because an operator can't have extra,
> defaulted parameters to carry the file and line.
>
> 6. It harmonizes with the eventual idea of making `Never` a universal
> bottom type, but we don't actually have to implement that today, because we
> can just overload `??` for now.
>
> Against these advantages, the only one I can see for `!!` is that it is
> terse. Terseness is good, especially for a feature which is competing with
> the single-character postfix `!` operator, but I can't help but be drawn to
> the flexibility and power of `??` with a `Never` expression on the
> right-hand side.
>

+1 to everything.

If terseness is the only clear advantage of a new operator that is meant to
be used sparsely, it's clear to me that the ?? Never form is better for the
Swift community as a whole.

--
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Víctor Pimentel Rodríguez via swift-evolution]

On Thu, Jun 29, 2017 at 12:45 PM, Elviro Rocca via swift-evolution <
swift-evolution@swift.org> wrote:

> From the user's standpoint, a crash is the worst thing possible, and
> should always be avoided. A failure doesn't need to be silent for user, the
> app can still communicate that there was an error with some kind of human
> readable message, and the developer can still be informed via any service
> that provides logging of non-fatal errors (there are many, most of them
> free).
>

Well, a persisted inconsistency is worse than a crash :P

During development, a crash can be informative, and that's what "assert"
> and things like that are for: even if I still prefer to not crash, and
> handle invariants by using specifically crafted types, I can understand the
> need for crashing in development, and from that standpoint I'd definitely
> support a proposal which goal is to make crashes caused by forced
> unwrapping more informative for the developer, or to force the developer to
> make them more informative (by substituting "!" with "!!").
>
> The reason why I'm not completely convinced is the fact that there's
> already "fatalError", and its presence already clearly indicates in the
> code that something could trap there, in a verbally-appropriate way. In
> this sense a new operator could encourage practices that in my opinion
> should not be encouraged.
>
>
> Elviro
>

To me this !! operator does not add enough value to put it in the standard
library. The existing force unwrap operator already works fine, and if
Never is really going to be a bottom type, then I don't know in which cases
the !! operator would be better.

Actually, for me it would be worse, because you could only call it with a
String or a function that returned a String. What happens if I want to call
a method that does some housekeeping and then ends with a fatalError? I
could not use the !! operator unless that method returns a String.

And finally, I would not want to find such code in a project with multiple
people involved, as my personal experience is that a single ! leads to
crashes in production sooner or later, and if you track such crashes it
would not be obvious why they happen. If that code is written by one person
and will not be published anywhere, I suppose you can use it, but either in
open source projects or in teams, I would avoid that operator like hell.

Instead of writing this (the original example, which by the way has a typo
:P):

guard !lastItem.isEmpty else { return }
let lastItem = array.last !! "Array must be non-empty"

I would just write this:

guard let lastItem = array.last else { return }

The first example seems reasonable enough: you know that the array is
empty, you just checked for it! But that array may possible be a property
of a class and it can be changed in another thread, so you can't be so
sure. And because software is usually never finished, some other team mate
can add more code between the first line and the second line, making it
easier to inadvertently change the array contents and thus not preserving
the initial invariants. The second example may need to be rewritten if the
requirements change, but it does not have the same drawbacks as the initial
example and, well, it's definitely less code and easier to read.

Anyway, can we provide a real world example? If some projects are already
defining this operator, working examples must exist and we can analyze how
this operator affects the code and which patterns are leveraged by it.

--
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Core team] Addressing the SE-0110 usability regression in Swift 4

[Víctor Pimentel Rodríguez via swift-evolution]

On Tue, 20 Jun 2017 at 01:41, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> Swift 3’s SE-0110
> 
>  eliminated
> the equivalence between function types that accept a single type and
> function types that take multiple arguments. However, for various 
> implementation
> reasons
> ,
> the implementation of SE-0110 (as well as the elimination of tuple “splat”
> behavior in SE-0029
> )
> was not fully completed.
>
> Swift 4 implemented more of SE-0110, which caused a fairly serious
> usability regression, particularly with closures. Here are a few simple
> examples involving closures that worked in Swift 3 but do not work in Swift
> 4:
>
> // #1: Works in Swift 3, error in Swift 4
> myDictionary.forEach {
>   print("\($0) -> \($1)")
> }
>
> // #2: Works in Swift 3, error in Swift 4
> myDictionary.forEach { key, value in
>   print("\(key) -> \(value)")
> }
>
> // #3: Works in Swift 3, error in Swift 4
> myDictionary.forEach { (key, value) in
>   print("\(key) -> \(value)")
> }
>
>
> Similar issues occur with passing multi-argument functions where a tuple
> argument is expected:
>
> // #4: Works in Swift 3, error in Swift 4
> _ = zip(array1, array2).map(+)
>
>
> In all of these cases, it is possible to write a closure that achieves the
> desired effect, but the result is more verbose and less intuitive:
>
> // Works in both Swift 3 and Swift 4
> myDictionary.forEach { element in
>   let (key, value) = element
>   print("\(key) -> \(value)")
> }
>
>
> The Swift core team feels that these usability regressions are
> unacceptable for Swift 4. There are a number of promising solutions that
> would provide a better model for closures and address the usability
> regression, but fully designing and implementing those are out of scope for
> Swift 4.  Therefore, we will “back out” the SE-0110 change regarding
> function arguments from Swift 4.
>
> Specifically, when passing an argument value of function type (including
> closures) to a parameter of function type, a multi-parameter argument
> function can be passed to a parameter whose function type accepts a single
> tuple (whose tuple elements match the parameter types of the argument
> function). Practically speaking, all of the examples #1-#4 will be accepted
> in both Swift 3 and Swift 4.
>
> We will revisit the design in this area post-Swift 4.
>
> - Doug
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
Thank you :)

--
Víctor Pimentel
-- 

D I G I T A LT E L C OE X P E R I E N C E

*[image: Imágenes integradas 5]*

*Víctor Pimentel Rodríguez · *Principal iOS Engineer
vpimen...@tuenti.com

+34 914 294 039  — +34 687 840 886

C/ Gran Vía, nº 28, 6ª planta — 28013 Madrid
Tuenti Technologies, S.L.

www.tu.com
www.tuenti.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Always flatten the single element tuple

[Víctor Pimentel Rodríguez via swift-evolution]

On Thu, Jun 8, 2017 at 3:01 PM, Vladimir.S <sva...@gmail.com> wrote:

> On 08.06.2017 12:17, Víctor Pimentel Rodríguez via swift-evolution wrote:
>
>> On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution <
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> Just a thought
>>
>> if parentheses is important, why the tuples are not?
>>
>>
>> This is stated on the proposal (and not in previous proposals):
>>
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/0110-distingish-single-tuple-arg.md
>>
>>   *
>>
>> We understand that this may be a departure from the current
>> convention that a set
>> of parentheses enclosing a single object are considered semantically
>> meaningless,
>> but it is the most natural way to differentiate between the two
>> situations
>> described above and would be a clearly-delineated one-time-only
>> exception.
>>
>>
>> <https://github.com/apple/swift-evolution/blob/master/propos
>> als/0110-distingish-single-tuple-arg.md#impact-on-existing-code>
>>
>> This proposal marks a one-time-only exception, to differentiate the
>> parenthesis needed to enclose a list of closure parameters and the
>> parenthesis needed for tuples. That's adding an exception for implementing
>> a regression.
>>
>> The more I think about it, the more I hate* this proposal.
>>
>> * Well, not _hate_, let's say slightly dislike :P
>>
>
> Please look here:
> https://github.com/apple/swift-evolution/blob/master/proposa
> ls/0066-standardize-function-type-syntax.md
>
> into "Proposed solution" section:
>
> Parentheses will be required in function types. Examples:
>
> Int -> Int   // error
> (Int) -> Int // function from Int to Int
> ((Int)) -> Int   // also function from Int to Int
>
> Int, Int -> Int  // error
> (Int, Int) -> Int// function from Int and Int to Int
> ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
>
> let f: () -> Int // function with no parameters
> let g: (()) -> Int   // function taking a single () parameter
> let h: ((())) -> Int // function taking a single () parameter
>
> f();   g(()); h(())  // correct
> f(()); g();   h()// errors
>
> Do you also hate* SE-0066?


I'm certainly not a fan, although I must say that it's funny to me to think
of the usefulness of a closure that only accepts a single parameter of type
"()", and how important it's to be able to model it. It was beautiful to me
how tuples and closure arguments were interchangeable, and I hope that some
day that feature will be back.

I'm also not a fan of SE-0029, the original proposal that removed tuple
splat and linked from SE-0110. I'm fine if it was better for the compiler
to remove that hacky implementation, but that proposal certainly has some
disdain for implicit tuple splat:

> This doesn’t seem like a positive contribution - this seems like a
"clever" feature, not a practical one.

And going back to SE-0110, I dislike this part too:

> The current behavior violates the principle of least surprise

People seems to get more surprised when you migrate some perfectly
reasonable code and have to use an intermediate tuple to achieve the same
effect as the code example in SE-0110 shows.

After rereading the proposals the motivation sections read more like "we
don't like this feature and it's useless" more than "we don't like this
implementation and it's dragging us". Looking at the final implementation
of this proposal (the third one!), I don't think the resulting code is
easier to maintain, actually the Swift 4 mode seems more complex:

https://github.com/apple/swift/pull/6133/files

I'm sorry, but I like this feature. Apart from Dictionary and similar, I'm
really going to miss being able to model every type of closure with the
type (T) -> U.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Always flatten the single element tuple

[Víctor Pimentel Rodríguez via swift-evolution]

On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution <
swift-evolution@swift.org> wrote:

> Just a thought
>
> if parentheses is important, why the tuples are not?
>

This is stated on the proposal (and not in previous proposals):

https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md

   -

   We understand that this may be a departure from the current convention
   that a set of parentheses enclosing a single object are considered
   semantically meaningless, but it is the most natural way to differentiate
   between the two situations described above and would be a
   clearly-delineated one-time-only exception.

This
proposal marks a one-time-only exception, to differentiate the parenthesis
needed to enclose a list of closure parameters and the parenthesis needed
for tuples. That's adding an exception for implementing a regression.

The more I think about it, the more I hate* this proposal.

* Well, not _hate_, let's say slightly dislike :P

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Always flatten the single element tuple

[Víctor Pimentel Rodríguez via swift-evolution]

On 7 Jun 2017, at 21:29, Xiaodi Wu  wrote:


SE-0110 may be an obvious extension of the proposed goal, but it is clear
> that it has been implemented in Swift 4, and that the consequences are
> derived of those changesets.
>
> Those "unwanted" consequences can be reverted by temporarily reverting
> SE-0110, without touching any other previous proposal.
>
> In no place I see Gwendal asking for full reversal of 5 proposals. He is
> just voicing something that a lot of app developers and library maintainers
> are not going to understand in September.
>
> For example, you can see all the changes needed in RXSwift so that it
> compiles to Swift 4:
>
> https://github.com/ReactiveX/RxSwift/pull/1282/commits/915e0
> 0fa6d1e59d58cd8c38dd6dc83765fc67fe4
>
> I would not want to migrate to Swift 4 an app using such framework.
>
> I asked you in my first reply to you, is your view that the distinction
> itself between (Int, Int) -> Int and ((Int, Int)) -> Int is problematic? If
> so, this is a very different discussion from seeking solutions to mitigate
> particular ergonomic issues that arise from the change. However, you have
> not answered the question.
>
>
> As far as I can see, the bigger usability regressions are caused when
> using generics, specially in collections and functional utilities. When you
> specify that type with a tuple, as in Dictionary, then all the related
> methods start receiving closures receiving tuples.
>
> Notice that allowing some syntactic sugar on the call site of those
> closures may not be enough, since you may have stored or passed a closure
> for customization purposes.
>

Can you illustrate this with an example? I’m not sure I understand what
you’re getting at here.


Sure. Let's say you want to filter some elements from a dictionary, and you
have this valid Swift 3 code:

let conversationsById: [String: Conversation]
let unreadConversations = conversationsById.filter { $1.isUnread }

Or:

let unreadConversations = conversationsById.filter { id, c in
return !id.isEmpty && c.isUnread
}

Neither of these expressions are permitted in Swift 4, but some syntactic
sugar can be added to allowing it again without the need of full tuple
splatting.

However, if for some reason you want to pass around a filter closure, you
will still have mismatch types:

func first(passing filter: (String, Conversation) -> Bool) -> Conversation?
{
return conversationsById.filter(filter).first?.value
}

This example is simple and useless and contrived, but it gets even worse
when you take generics into account to catch any type of closure.

This behavior is so hurtful to functional style programming, that I think
> either SE-0110 should be reverted, or alternatives like this Susan proposal
> should be implemented.
>

To be clear, what you and Gwendal are objecting to is the loss of tuple
splatting, is it not? Again, SE-0110 is only the final piece; SE-0029 is
what removed implicit tuple splatting. As that proposal said, a properly
designed explicit tuple splatting can be considered if there’s demand, and
it was understood that removing this functionality would be a regression
and nonetheless the decision for removal was still deliberately undertaken.
Re-reading that proposal, the rationale was that it never worked correctly
to begin with, and the barrier for bringing it back is that it requires
considerable effort to design and implement the feature correctly.

I'm sorry if there has been any disrespect for my part, I appreciate what
you all do here. But sometimes it's a bit frustrating having to explain why
something that seems obvious to us is not obvious to others.

I think that you have a bigger picture from the Swift Evolution point, but
the thing is that Swift users like me doesn't have that context, and we are
baffled when we encounter that some pretty simple code turns into a weird
thing in a migration. I have linked to several real examples out there, and
it seems to be a popular opinion. Nevertheless, it was Tony Parker's mail
the one that kindled this discussion with a really simple question.

It may be the last piece, but it is the piece that impacted simple code the
most, or at least the one that had the most unexpected consequences.
Certainly that proposal does not contain nearly enough code examples or
goes deeply enough. And this is subjective, but for me this isn't true:
"Minor changes to user code may be required if this proposal is accepted."

The fact that it affects even the standard library shows how hurtful
removing this feature is. It's not a nice-to-have feature or a
somewhat-useful feature, it's that right now it's very difficult to model
something as essential as Dictionary with a nice-to-use API. So lots of
other custom types will suffer too.

If we all agree that this is a loss of ergonomics, then the Core Team have
several options for Swift 4:

1. Do nothing.
2. Revert SE-0110 related changes.
3. Add a complex tuple-splatting feature.
4. Add some 

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

[Víctor Pimentel Rodríguez via swift-evolution]

On Wed, Jun 7, 2017 at 7:35 PM, Adam Sharp via swift-evolution <
swift-evolution@swift.org> wrote:

> The new smart key path feature is really lovely, and feels like a great
> addition to Swift.
>
> It seems like it might be straightforward to add overloads of `map` and
> `flatMap` to the standard library to make use of the new functionality:
>
> let managers = flatOrganisation.managers
> let allEmployees = Set(managers.flatMap(\.directReports))
> let employeeNames = Set(allEmployees.map(\.name))
>
> This feels like a really natural way of working with key paths in a
> functional style. It makes a lot of sense for collections, and possibly for
> Optional too (although as far as I can see optional chaining is more or
> less equivalent, and with more compact syntax).
>
> I’m hoping that this might be low-hanging fruit that could be considered
> for the Swift 4 release. I’d be happy to have a go at writing a proposal if
> there’s interest!
>
> –Adam
>

+1, it seems like a wonderful addition that would make a lot of code much
shorter.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Always flatten the single element tuple

[Víctor Pimentel Rodríguez via swift-evolution]

On 7 Jun 2017, at 18:10, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

On Wed, Jun 7, 2017 at 10:03 Gwendal Roué  wrote:

> Le 7 juin 2017 à 15:52, Xiaodi Wu  a écrit :
>
> Let’s clarify: you just wrote that you have problems with SE-0029,
> SE-0066, SE-0110, and “before,” did you not?
>
>
> WTF? No I did not (citation below)!
>
> Le 7 juin 2017 à 15:02, Gwendal Roué  a écrit :
>
> Le 7 juin 2017 à 14:42, Vladimir.S  a écrit :
>
>
> Gwendal, again, you are proposing to revert not just SE-0110 and SE-0066
> but mainly SE-0029 "Remove implicit tuple splat behavior from function
> applications"
> (https://github.com/apple/swift-evolution/blob/master/
> proposals/0029-remove-implicit-tuple-splat.md)
>
>
> Do you mean that the regressions Stephen and I have shown have been
> introduced not only by SE-0110, but before SE-0066, and SE-0029?
>
>
> Your attitude is obnoxious. Enough Swift evolution for me today.
>

Please refrain from personal attacks. Are we reading the same sentence? I
see that you literally listed three proposals (and “before”) and blamed
them for “regressions” that you want to reverse. If that’s not your
meaning, what do you mean?


In the conversation you can see that Vladimir stated that proposing to
revert this proposal would also mean reverting other previous proposals.

Gwendal is only asking back if the bug was introduced by the changesets
related to those proposals or by the changesets related to SE-0110.

Asking back is very different from blaming those proposals, or asking for
reversal of Swift 3 proposals. SE-0110 may be an obvious extension of the
proposed goal, but it is clear that it has been implemented in Swift 4, and
that the consequences are derived of those changesets.

Those "unwanted" consequences can be reverted by temporarily reverting
SE-0110, without touching any other previous proposal.

In no place I see Gwendal asking for full reversal of 5 proposals. He is
just voicing something that a lot of app developers and library maintainers
are not going to understand in September.

For example, you can see all the changes needed in RXSwift so that it
compiles to Swift 4:

https://github.com/ReactiveX/RxSwift/pull/1282/commits/915e00fa6d1e59d58cd8c38dd6dc83765fc67fe4

I would not want to migrate to Swift 4 an app using such framework.

I asked you in my first reply to you, is your view that the distinction
itself between (Int, Int) -> Int and ((Int, Int)) -> Int is problematic? If
so, this is a very different discussion from seeking solutions to mitigate
particular ergonomic issues that arise from the change. However, you have
not answered the question.


As far as I can see, the bigger usability regressions are caused when using
generics, specially in collections and functional utilities. When you
specify that type with a tuple, as in Dictionary, then all the related
methods start receiving closures receiving tuples.

Notice that allowing some syntactic sugar on the call site of those
closures may not be enough, since you may have stored or passed a closure
for customization purposes.

This behavior is so hurtful to functional style programming, that I think
either SE-0110 should be reverted, or alternatives like this Susan proposal
should be implemented. However, reverting may be safer and faster than
adding more new code to the compiler with such short time until Swift 4
release.

Of course that´s the Core team call, if the gains in the compiler code is
so great then we'll have to live with this regression. After WWDC I hope
that they notify their decision.

--
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel Rodríguez via swift-evolution]

On Tue, Jun 6, 2017 at 3:30 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm just trying to understand your opinion.
> Let me know, what result do you *expect* for this Swift4 code given what
> SE-0066 requires for function types:
>
> func foo(x : (Int, Int))->() {}
>
> print(type(of: foo))  // ??
> print(foo is (_: Int, _: Int)->())  // ??
>
>
> Vladimir.
>

I think most developers would not care about or notice that discrepancy,
while most will encounter the regression in closures and specially in the
Dictionary API. In fact most developers will have this reaction:

https://owensd.io/2017/06/01/se-110-fallout-im-confused/

Please, I don't mean that the type discrepancy should not be changed or
that the proposals have not value, it's just a matter of priorities here.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel Rodríguez via swift-evolution]

On Mon, Jun 5, 2017 at 9:31 AM, Gwendal Roué via swift-evolution <
swift-evolution@swift.org> wrote:

> The motivation section is not at all about any "type checker problem".
> It's about a postulate that has been proven horribly source-breaking, and
> counter-productive. The type safety argument is moot. The principle of
> least surprise has been blown away by SE-0110, putting Swift aside from the
> majority of other languages.
>
> I'm surprised that everybody tries to workaround SE-0110 consequences,
> admitting that it's relevant, instead of revisiting SE-0110 at its very
> root.
>
> Gwendal
>

+1 to this.

In practice, we have seen that the previous behaviour was incredibly
versatile and it allowed for more expressive code; using tuples in generic
types is much more pleasant to use (eg: Dictionary and similar
collections). I suppose most users of that Dictionary API did not know that
those blocks were accepting tuples and not several parameters, but still
they were productive with those APIs. Now we will require them to know what
I consider is a implementation detail, which adds a small cognitive load
when they try to use them.

So, which syntax is considered to be better? To me, every proposed syntax
is worse than the previous one, even more considering that this will be a
breaking change. And we do not need to invent some examples, we have real
usages that we can reason about:

https://github.com/Alamofire/Alamofire/blob/c8700ac7ea6b7efa7200e2920bf528e88b4dbee6/Source/ParameterEncoding.swift#L245

return components.map { "\($0)=\($1)" }.joined(separator: "&")

I suppose that with Swift 4 that line of code will be rewritten as this:

return components.map { "\($0.0)=\($0.1)" }.joined(separator: "&")

No matter the workaround, that will be the case. That is not Swift code I
want to write nor maintain.

Can't we delay the release of SE-0110 until Swift 5, where we can reason
more about its consequences? Are the gains in compilation times so
impressive? Do we want to hinder such code patterns because of "type
safety"? Are there any real world examples where that has been an issue?

Thanks,

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel Rodríguez via swift-evolution]

On Fri, Jun 2, 2017 at 1:53 AM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> I vote to revert it to current behavior.  Then we can take time to come up
> with the correct answer for future Swift.
>
> If we don’t revert and then end up changing it again later, we will break
> everybody’s code twice...
>
> Thanks,
> Jon
>

+1

This source-breaking change affects lots of libraries, as it has been
shown. It seems very late in Swift 4 to be discussing alternative syntaxes,
so the best action for me would be revert it and revisit this in the next
version.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel Rodríguez via swift-evolution]

On Fri, May 26, 2017 at 7:57 AM, Gwendal Roué via swift-evolution <
swift-evolution@swift.org> wrote:

> > Furthermore, this probably comes up most commonly with dictionaries,
> since they're a sequence of tuples. The element tuple for dictionaries has
> element labels (key: Key, value: Value), so instead of writing `{ tuple in
> let (key, value) = tuple; f(key, value) }`, you could use the implicit
> argument and write `{ f($0.key, $0.value) }`.
> >
> > -Joe
>
> I've migrated a project from Swift 3 to Swift 4 (relevant commit:
> https://github.com/groue/GRDB.swift/commit/4f26cbcacf7b783c9c503f2909f2eb
> 03ef7930fe)
>
> Joe is right, dictionaries, as handy as they are, are particularly
> affected. But $0 is hardly a panacea.
>
> What I regret the most with the change is the lost ability to give
> *relevant names* to tuple elements (and sometimes with the forced
> introduction of a phony variable that has no relevant name (like "pair").
>
> Here are below four examples of regressions introduced by SE-0110:
>
> Example 1
> -return columns.index { (column, _) in column.lowercased() ==
> lowercaseName }
> +return columns.index { $0.0.lowercased() == lowercaseName }
>
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { (pair) -> (Int, String) in
> +let mappedColumn = pair.key
> +let baseColumn = pair.value
>
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator:
> ", ")))" }
> +.map { "\($0.key)(\($0.value.sorted().joined(separator:
> ", ")))" }
>
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased()
> == orderedColumn.lowercased() }
> +dictionary.first { $0.key.lowercased() ==
> orderedColumn.lowercased() }
>
> Gwendal Roué


I have also migrated a couple of projects, and this appeared in every one
of them even if we didn't use any RX library. For example Alamofire has a
couple of errors due to this change. And the resulting code after applying
the Fix-It is, well, not pretty.

As you say, it will basically affect a lot of Dictionary API surface, not
only forEach but map, filter, etc.

SE-0110 seems to hinder the functional programming style, and I would
revert it because right now we know that the proposal was wrong as it
stated that the impact on existing code may be that only "minor" changes to
user code may be required:


https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md
Impact on existing code

Minor changes to user code may be required if this proposal is accepted.
Alternatives
considered

Don't make this change.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

[Víctor Pimentel Rodríguez via swift-evolution]

On Fri, May 12, 2017 at 6:56 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> I assume you're talking about the type restrictions on exporting Swift
> functions as @objc.  We have the technical ability to bridge any Swift
> value to Objective-C as an opaque object, but that wouldn't actually
> produce meaningful APIs on the ObjC side; we have to have some sort of
> tighter policy than that.  Today, that policy is to allow export when
> there's an obvious, idiomatic analogue in Objective-C.  Exporting Int? as
> an optional NSNumber does not feel obvious and idiomatic when we would
> export Int as NSInteger.  It feels like reaching for an arbitrary solution.


Actually Swift already export Ints as NSNumbers in other contexts when
types like Int are used in generic constraints, particularly value types
like Array or Dictionary. For example, a variable of type [Int] gets
bridged over as a NSArray *.

For such purposes Swift already has types like _SwiftTypePreservingNSNumber
, a subclass of NSNumber.

If that can apply to Array or Dictionary, the same reasoning
can be applied to the Optional.

I mean, I'm not saying that there are no reasons to disallow it, but it
doesn't seem an arbitrary solution if in other contexts Swift is already
doing that.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] `enum` case count feature

[Víctor Pimentel Rodríguez via swift-evolution]

On Wed, May 10, 2017 at 8:52 PM, Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> I use a enum (with a Int raw value) for sections in a table view, so
> whenever the table view asks for the number of rows I pass in the number of
> cases. Currently, I’m doing something like this:
>
> enum Sections: Int {
> case section1: 0
> case section2
> case section3
> case _count
> }
>
> Obviously, this cases issues in switch statements since I need to handle
> the _count case with an assertion, but other than that it works rather well.
>

Yes, it is useful for Table Views, and for pets projects I have done it, at
the expense of handling that case due to exhaustive switches. However as
Brent stated, it does not fit well into Swift 4 at this late stage, so
maybe if better introspection is introduced in Swift 5 it will fit better.

Just to be clear, if the proposal that Brent stated gets accepted you could
do something like this:

let count = Sections.allCases.count

And you won't have to put that assert never again.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Víctor Pimentel Rodríguez via swift-evolution]

On Friday, April 7, 2017, Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> In a discussion about inferring parameter types from default value, Slava
> brought up some performance problems caused by type inference for stored
> properties in side types:
>
> https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170313/033882.html
>
> Towards the end, the post mentioned that some Swift team members
> contemplated requiring types for stored properties in type declarations. I
> think this idea deserves some more attention. Hence this last minute
> idea-floating.
>
> In addition to solving a performance headache in implementation, there're
> always the general benefit of making type declartion more explicit and
> readable (clarity for reader should out-weigh pleasure of the author).
> Making the
> language slightly more consistent (we are not inferring types for default
> parameter values in function anyways).
>
> The cons for doing this are obvious too: the inference makes the language
> feels more friendly and is, undoubtedly, a beloved feature for many. This
> would be a source breaking change.
>
> Just thought I'd float the idea to gather some quick reaction. What do
> y'all think?
>

I think this chabge would be too source breaking for Swift 4. Just for that
reason I would not implement it.

Also, I think the Core team talked about having specific themes for the
upcoming releases. I would very much like Swift 5 to have improving compile
times as a major theme.

Under such theme, maybe it makes sense to forbid complex expressions
in stored properties definitions with no explicit type. Forbidding literals
or direct function calls would remove a useful feature and the gains would
not be much, IMHO.

--
Víctor Pimentel

-- 

INNOVATION IN PERSONAL COMMS


*[image: Imágenes integradas 5]*

*Víctor Pimentel Rodríguez · *Principal iOS Engineer
vpimen...@tuenti.com

+34 914 294 039 <+34914294039> — +34 687 840 886 <+34687840886>
C/ Gran Vía, nº 28, 6ª planta — 28013 Madrid
Tuenti Technologies, S.L.

www.tu.com
www.tuenti.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Type-based ‘private’ access within a file

[Víctor Pimentel Rodríguez via swift-evolution]

On Fri, Apr 7, 2017 at 5:47 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> Setting aside source compatibility concerns for a brief moment, is there
> anyone who would choose this approach over reverting SE-0025, renaming the
> current modifier, or maintaining the current access modifiers?  If this is
> nobody’s first choice that should be a big cautionary sign.
>

After migrating several codebases, I think the best for me would be moving
in the direction explained in this proposal. For these reasons:

- In the migration to Swift 4, my team's code would work right away,
without any changes at all (well, at least because of this proposal).
- When my team have the time to do it, we can replace all of our
fileprivate usages for private ones, since we just use them to share
properties between same-file extensions.

So at the end this proposal will impact my team very little at first, we
will have less merge issues (hello Swift 3) and eventually the code will
be, for us, cleaner and easier to read. All the other proposals will not
give my team this smooth transition.

And, IMHO, I think that having access to really private details between two
types probably leads to programmer errors, so my next preferred step after
this one would be removing fileprivate altogether.

But I understand that Swift as a language must be gradually shaped.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Víctor Pimentel Rodríguez via swift-evolution]

On Fri, Apr 7, 2017 at 1:10 AM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md


>- What is your evaluation of the proposal?
>
> Strongly +1, this is definitely a strong step in a good direction, and it
would make Swift more pleasant to work with for the programmers that use
extensions to organize their code.

As I see it by reading the strong opinions about this proposal in the
mailing list, we can split the affected groups into three:

1. Programmers that do not use extensions in the same file to organize
their code.
2. Programmers that use extensions to organize their code but do not care
about sharing implementation details in the same file within a type.
3. Programmers that use extensions to organize their code but care about
sharing implementation details in the same file within a type.

The first bunch is not affected at all by this proposal, no matter the
programmer style that they choose (like spliting extensions in separate
files). They may feel that nothing improves with this, or that some
opportunity is missed by this, or that SE-0025

will
never be reverted if this proposal gets accepted. Nevertheless, this change
do not affect their code at all, even if it pushes the community to other
programming style.

The second bunch, were I live, will receive this change with open arms. We
think that if you are writing in a file you have access to the code in that
file and can see/modify all the usages. It may be too little for some, but
this proposal clearly improves the current situation for this group.

The third bunch are the ones whose code can be hurt, that is clear and I'm
not going to judge their reasons here. I suppose that this group was very
much in favor of the divisive SE-0025
.
But I'm not seeing this group happy with any proposal that does not
includes more granularity, like another scope modifier, and any such
proposal will hurt the first and second groups.

I don't know how big or representatives are these groups, I suppose the
first group will include the majority of newcomers and the second group
will include more seasoned Cocoa programmers, but that is just my
impression.

Also, I like this change very much because the Swift 4 migration will be
painlessly for basically everyone, unlike the Swift 3 fileprivate
migration. No code should be changed if you don't want it, and the code
will keep working the same. The only case where you can have problems
migrating would be if you had:

struct House {
private func openWindows() {}
}

extension House {
private func openWindows() {}
}

But that is not even accepted by the compiler right now (at least not in
the Linux one).


>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
>
Yes. This would be the thing that would rush me to upgrade to Swift 4 as
fast as possible, since it would remove the single major painpoint that I
had with Swift syntax.


>- Does this proposal fit well with the feel and direction of Swift?
>
>
Yes, it encourages again the use of extensions, not that it needed to.


>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
>
Not applicable, I think.


>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
>
Daily experience working with fileprivate in Swift since the first beta of
Swift 3.

-- 

INNOVATION IN PERSONAL COMMS


*[image: Imágenes integradas 5]*

*Víctor Pimentel Rodríguez · *Principal iOS Engineer
vpimen...@tuenti.com

+34 914 294 039  — +34 687 840 886

C/ Gran Vía, nº 28, 6ª planta — 28013 Madrid
Tuenti Technologies, S.L.

www.tu.com
www.tuenti.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Víctor Pimentel Rodríguez via swift-evolution]

> On Thu, Apr 6, 2017 at 9:35 PM Joe Groff via swift-evolution 
>  wrote:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
> 
>   • What is your evaluation of the proposal?

+1

The first questions that pop into mind are "how do I write the character 
sequence """? And the literal \(something)?".

But if you think twice, those sequences would need to be escaped just like now 
with the existing simple string literals. So in the end if you know how to 
escape in a one-line literal, you know how to escape in a multi-line literal.

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

Yes. Though I would use it not every day, sometimes I really need this syntax 
and I would have loved to have it. Also, from my own experience, this is even 
more important for server-side Swift apps.

>   • 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 feel that this proposal compares to those?

Very favorably, I think it trumps any other option that I've known and used, 
even some template languages.

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

I've followed the discussion and read the (small) proposal.

--
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

[Víctor Pimentel Rodríguez via swift-evolution]

On Thu, Apr 6, 2017 at 12:44 AM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> On that note: ‘containsOnly' is still my favorite by a wide margin.  I
> know it is longer than ‘all’, but it’s behavior is much clearer (especially
> for those of us who have never used or heard of ‘all’ in other languages),
> and it’s relationship with ‘contains’ is also very clear.
>

Also +1 to containsOnly for this very reason.

In other languages (Python, Ruby, etc) that have an `all` method, they also
have an `any` method, thus maintaining certain consistency.

In the Swift standard library that `any` method is called `contains`, so
`containsOnly` matches nicely that consistency.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0164: Remove final support in protocol extensions

[Víctor Pimentel Rodríguez via swift-evolution]

On Thu, Apr 6, 2017 at 12:05 AM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
>- What is your evaluation of the proposal?
>
> +1

This small inconsistency can lead to pretty hard debugging session.

I think the protocols will still need some extra work because, as Howard
Lovatt said, people get confused about which method will be called when
methods of a type conflict with methods in a protocol extension.

But this is a good small step towards a more consistent model, so it seems
good to me.


>- 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 feel that this proposal compares to those?
>
> N/A


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

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

[Víctor Pimentel Rodríguez via swift-evolution]

Sorry to be late :/

On Fri, Mar 31, 2017 at 5:29 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:
>
> * What is your evaluation of the proposal?
>

More positive than the first one, but still some rough edges.

One concern that I still have is that if we use @objcMembers, @nonobjc
methods/properties are going to be even trickier to find.

If such modifier existed, I would like the compiler to warn me of public
methods/properties that cannot be bridged to ObjC, because I have
explicitly told the compiler that I want this object to live in the ObjC
runtime. Of course, with a fixit recommending something like explicitly
using @nonobjc.

* 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, I think.

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

In-depth study of the previous version and this new one too.

-- 

Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Type-based ‘private’ access within a file

[Víctor Pimentel Rodríguez via swift-evolution]

On Mon, Apr 3, 2017 at 8:34 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> The design, specifically, is that a “private” member declared within a
> type “X” or an extension thereof would be accessible from:
>
> * An extension of “X” in the same file
> * The definition of “X”, if it occurs in the same file
> * A nested type (or extension thereof) of one of the above that occurs in
> the same file
>

Strongly +1, and I fully agree with David Hart draft.

As an app developer that works with Swift everyday, this will fix most of
my pain-points with scoped access. It will not only ease a very popular use
of extensions, but when asking a new developer this is the default that
makes more sense.

Being selfish, with this proposal, you could even delete fileprivate, I
would never use it or recommend it. If you want a type private to a file,
enclose it under other type.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Nested extensions and stored properties

[Víctor Pimentel Rodríguez via swift-evolution]

On Thu, Mar 30, 2017 at 1:16 PM, Vladimir.S via swift-evolution
 wrote:
> So, both top level extensions and nested would have only 'fileprivate',
> 'internal' or 'public'. 'scoped' is not allowed for them(if we accept the
> above suggestions):
>
> class MyType { // internal
>   public var a = 10 // internal(because of type's access level)
>   var b = 20 // internal
>   scoped var c = 30 // scoped for type and for nested extensions
>
>   // default and max level is fileprivate, bounded by type's access level
>   fileprivate extension MyProtoA {
> scoped var d = 10 // scoped for extension, inaccessible outside  of it
>
> var e = 20 // fileprivate
> internal var f = 20 // fileprivate
> public var g = 30 // fileprivate
>
> func foo() { print(c, i, m) } // can access c, i, m
>   }
>
>   // default and max level is internal, bounded by type's access level
>   extension MyProtoB {
> scoped var h = 40 // scoped for extension, inaccessible outside  of it
>
> var i = 50 // internal
> internal var j = 60 // internal
> public var k = 70 // public->internal(type's access level)
>   }
>
>   // default and max level is public, bounded by type's access level

I think this is internal even if declared public.

>   public extension MyProtoC {
> scoped var l = 80 // scoped for extension, inaccessible outside  of it
>
> var m = 90 // public -> internal(type's access level)
> internal var n = 100 // internal
> public var o = 110 // public->internal(type's access level)
>   }
> }
>
> Do you see any drawbacks in such design? (given that we disallow scoped
> access modifier at top level of file and for nested extensions in type)

To me it's very difficult to understand at first glance what's
happening in that code, or what is the intent for those modifiers. For
example, in my mind it takes way too much to compute the access level
for a variable inside a nested extension.

For me it's immensely useful that the compilers warns you when you
declare a subtype/property/method with an wider access modifier than
the current scope.

In general the whole proposal looks complicated, and for me it's hard
to imagine an use case for such needs.

It probably be because of my own limitations, but in my day to day and
when reviewing open source code, I crave for simpler access levels,
not for more granularity. The only friction that I see is having to
declare a method/property fileprivate instead of private because you
want to use from an extension in the same file.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Víctor Pimentel Rodríguez via swift-evolution]

> What is your evaluation of the proposal?

+1, it would improve my team's codebase.

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

Yes.

In our case we are using extensions very liberally to organize our
code, and we are using fileprivate just for having access to stored
properties from extensions. A quick search tells us that in our main
target:

- fileprivate: 1483 uses
- private: 424 uses

So it's roughly 3.5x for fileprivate for us. Most of those private
uses are private extensions, where we keep all of our private methods
organized (and that way we don't have to specify that level for every
method). But we cannot do the same for stored properties and we are
forced to use the keyword again and again, several lines in a row.

The problem is that *we never want to use fileprivate*, we are just
*forced to use it*. After a while it's a habit, but it's just ugly to
look at and the code is harder to read. We don't want to have that
detail in our head, in the same way that Swift removes other
unimportant details that we had when working with just Objective-C.

Being selfish, expanding the notion of private to extensions within
the same file would be enough for us. But we also don't see any
additional value in having the fileprivate keyword, and while there
are several code styles that lead to good code, we don't think that
code styles that access other types private information leads to good
design.

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

Yes. This changes was implemented having no references from other
languages, and with zero experience in shipping code. Now we have that
experience, and it shows that for a significantly part of the
community this was hurtful. The fact that with a popular code style
fileprivate is used way more than intended tells something about this.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

While I have no experience with any fileprivate/private language, the
current scope distinctions are hard to explain. At first sight it's
weird that for file-level declarations private and fileprivate means
the same, even if it makes sense when you think about it.

The fact that other popular languages with scope-based access don't
have extensions means that maybe we cannot model Swift scopes based on
them.

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

In-depth study and shipping experience with private since Swift 2 and
with fileprivate since Swift 3 was released.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Víctor Pimentel Rodríguez via swift-evolution]

Sorry if this is too long, but this proposal would greatly impact
developers such as myself.

> * What is your evaluation of the proposal?

Strongly against it.

I currently work in an iOS project with around 15 developers where the
main target (not counting extensions or frameworks) has +1600 ObjC
classes and +600 Swift files, and we are relying in the mix and match
for DI and testability reasons. Swift 3 migration was not easy, I tell
you ;)

In practice for us this change will mean that we will need prefix
every method and property with @objc for most of our NSObject
subclasses. And if we left any of them out the compiler will not warn
us and it could end up in production crashes and, worse, undefined
behaviour. While we don't want to add such @objc annotation, we surely
don't want those crashes.

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

My understanding is that the main problem is: "[...] Swift's rules for
inference of @objc are fairly baroque, and it is often unclear to
users when @objc will be inferred.".

Yes, that problem is significant enough and in real world apps that
live in the ObjC runtime we are seeing that this slows down a bit the
development and crashes are likely to end up in production. We are
careful enough so that not we don't have so many crashes, but in
development we have many wtf moments where we revisit why our code
isn't working as expected. This is very difficult to explain to
newcomers.

But I'm just not seeing how this proposal would fix this problem, if
any, it would make it worse and introduce lots of more bugs.

In fact the proposal states that some of the detected problems "are
out-of-scope". I'm very concerned by that, I see that the proposal has
been carefully thought but that avoiding bugs/crashes in shipping apps
is not a top priority.

This post kind of summarizes the current state of method dispatch within Swift:

https://www.raizlabs.com/dev/2016/12/swift-method-dispatch/

If I were to create an updated table with the proposed changes, would
that table be more complicated or less complicated? From my point of
view, it would complicate things even more.

So for me the important thing to ask would be: How do we want NSObject
subclasses to look like so that they are safer, faster and more
expressive than now?

I understand that the Core team may not be aligned with this view
since you don't want to compromise speed in such objects, even though
for shipping apps the speed gained at this level is much less
appreciated that the safety. But for me a NSObject subclass should
work as close as possible as if it was in ObjC. So I agree with the
Brian King post in that NSObject subclasses should always be dynamic.
In fact:

- If you inherit from NSObject, I would expose every method/property
to the ObjC runtime.
- If you inherit from NSObject, any property/method that cannot be
exposed to the ObjC runtime should have a @nonobjc annotation. The
compiler could easily enforce this.
- I would remove the dynamic keyword, since that is not a pure Swift
construct (not forever, but at least until it becomes a pure Swift
construct).
- I would remove the need for @objc except in the case of a name
refinement and protocol declaration. This includes optional methods in
@objc protocols.
- (I'm less sure about this) Private methods in NSObject subclasses
written in Swift should act as ObjC non-visible methods, they should
be dynamic but they should not appear in the bridging header.

These changes do not affect pure Swift classes or structs, so the fact
that right now Cocoa and other frameworks force you to use NSObject
subclasses in specific situations do not prevent you from using joyful
pure-Swift collaborators. Since it will make everything much more
predictable, this change will probably bump the use of pure Swift
constructs, which will make those pieces of code much more portable
than semi-NSObject classes. Of course this is completely out of scope
for this review, but it shows that there is another way of making
things simpler for every developer that now needs to write NSObject
subclasses.

In the future and in my particular case, I'm dreaming of Apple
frameworks that do not rely in the ObjC runtime, and of Swift
improvements to introspection and other dynamic features. In that
dream, your classes should not inherit from NSObject if you don't
want, and any of the changes that the community makes to @objc
inference will not apply.

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

As stated in https://swift.org/about/, the main goals of Swift are:

1. Safety, to the end that "developer mistakes should be caught before
software is in production".
2. Fastness, to the end that "Swift is intended as a replacement for
C-based languages (C, C++, and Objective-C). As such, Swift must be
comparable to those languages in performance for most tasks.
Performance must also be predictable and consistent [...]"
3. Expressiveness,