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

[Andrey Tarantsov via swift-evolution]

> What is your evaluation of the proposal?



Very strong -1. Drew has said it all.



A few extra points:



* If you split a class into a bunch of extensions, chances are it's a
  large class, and fileprivate keyword provides crucial *documentation*
  on which methods and fields are accessed from outside the scope. Even
  if someone blindly uses private until compiler complains, then
  switches to fileprivate without thinking, there's still value when
  reading the code. (This has been mentioned as one of the points
  against scoped private.)


* Encapsulation is in the spirit of Swift's safety goals, we want to
  encourage it.


* // MARK is perfectly fine for tightly-coupled class bodies, so if you
  find yourself using tons of fileprivate, consider switching to a
  single body with marks


* I really like the point that we should uphold the original decision
  unless we find new compelling arguments that were not considered
  initially.




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


No. I haven't personally seen any complains about this feature in my
circles; everyone is happy about tighter access controls.




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



It feels actively against the safety and readability goals of Swift.





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


This has been beaten to death in the original proposal.





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


Thorough reading of the first half of this discussion, and active
participation in the original discussion (as well as writing and
shipping lots of Swift code since Swift 0.x).


A.


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

Re: [swift-evolution] SE-0066 Reaction

[Andrey Tarantsov via swift-evolution]

Hey, 

I'm inserting these opinions into almost every FP discussion, for which I'm 
sorry, but I believe it's important to remind everyone that there's the rest of 
us who will run away from Swift if it becomes too FP-y.

> One of the things that I have noticed over the last year or so of working 
> with Swift is a trend in the community of libriaries being written for Swift 
> towards some of these "system semantics" (i.e., functional paradigms) like 
> applicatives and such.

Just as an example of a different selection bias, I saw a couple of those, 
digged in for a little bit and then ran far, far away. I haven't seen any 
FP-related Swift libraries after that.

I absolutely don't have an impression that Swift has any affinity towards being 
functional. To me, it embraces mutability and higher-level object design 
aspects (like protocols) while taking only the bits of FP that are actually 
useful (e.g. collection methods).

I don't have any data, but I can bet that most software developers on iOS and 
Mac platforms welcome that, and don't really want the move towards FP.

A.

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

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Andrey Tarantsov via swift-evolution]

Let me bump this thread. How do we move forward?

Here's an interface of another Swift class I've just made (slowly rewriting my 
Obj-C components to Swift here):

public class SoloContainerViewController: UIViewController {

private var _contentViewController: UIViewController?

public var contentViewController: UIViewController?  // delegates to 
setContentViewController:animated:completion:

public init(contentViewController: UIViewController?) { ... }

public required init?(coder aDecoder: NSCoder) { ... }

public override func viewDidLoad() { ... }

public func setContentViewController(contentViewController: 
UIViewController?, animated: Bool, completion completionBlock: 
dispatch_block_t?) { ... }

public /*protected*/ func transition(fromView oldView: UIView?, toView 
newView: UIView?, animated: Bool, completion completionBlock: (finished: Bool) 
-> Void) { ... }

public /*protected*/ func 
willTransitionToContentViewController(newViewController: UIViewController?) { 
... }

public /*protected*/ func 
didTransitionFromContentViewController(oldViewController: UIViewController?) { 
... }

}

This is madness, we have to do SOMETHING!

This class is designed to be subclassed, with a bunch of hooks that subclasses 
may be interested in. Most of the reusable views and view controllers that I 
make look like this.

Even when I use delegates, I still forward delegate calls through overridable 
protected methods, based on my long history of subclassing UIScrollView (and 
other controls) and wishing that the subclass had access to the delegate 
methods.

Nobody outside of the class should be interested in those protected methods; 
they are not safe to call, they're override points.

And I often have to pick very telling method names, so that I don't end up 
accidentally calling one of those methods from outside. Sometimes that's fairly 
hard, like when there's a public save(), a private saveNow() and a protected 
saveContent().


Our best consensus the last time was:

>>> My point is that "protected" *isn't* access control. If we added it, it 
>>> would have to be as an independent modifier.
> 
> Okay. So you see it as “public subclassonly”, leaving space for “internal 
> subclassonly” (which makes sense, although not as important in practice).
> 
> I can agree with that, let's consider it a new strawman.


So how do we move forward?

A.

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

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

[Andrey Tarantsov via swift-evolution]

> I do not think that I was conflating these two aspects. Using #type(self) 
> would return the particular type of the current instance (dynamic type) while 
> using #type(A.var) would return the declared (static) type of the property.

Taras, to me personally, #something suggests evaluation at compilation time, so 
I would be *extremely* surprised if #type would return a dynamic type, and 
#dynamictype is just an abomination, in every way worse than 
something.dynamicType.

A.

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

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

[Andrey Tarantsov via swift-evolution]

Chris,

> Given all this, I think it makes sense to go for syntactic uniformity between 
> parameter list and function types, and just require parenthesis on the 
> argument list.  The types above can be trivially written as:
> 
>  (Int) -> Float
>  (String) -> ()

I don't care about this particular question too much, although I still prefer 
less parenthesis where possible.

But I fear that going this way, we'll soon arrive at requiring parenthesis for 
the block arguments:

do_something { foo in 
  ...
}

and that (the parenthesis in blocks) is something I would love to avoid.

Note how all of your arguments would apply to the blocks as well.

A.



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

Re: [swift-evolution] TreeLiteralConvertible

[Andrey Tarantsov via swift-evolution]

Hey!

>> Can you please give us a few real-world examples where initializing a 
>> nontrivial tree-like data structure in code would be useful?
> 
> I suppose we always prefer to move *all* data into databases or files with 
> dedicated data formats, *including* arrays, strings, dictionaries, etc. Sure. 
> But it would be rather underwhelming if you could not also just instantiate 
> an array or a string from a literal.

> Likewise, I find it a little deflating that I cannot express a piece of JSON 
> in code. 
> 
> Given the *simplicity* of these structures, it seems it should not be beyond 
> Swift to represent them in code with ease and elegance. And to begin with, 
> all we need are those couple of protocols.


Did you just... sidestep the question? :-)

The reason we want dictionary and array literals is that because they're needed 
in the real code bases, everywhere, not just for the abstract beauty of the 
langauge. I can certainly list many specific use cases for both array and 
dictionary literals, with code examples.

I can't think of any real use cases for the kind of literals you want, though, 
hence the question. (And I don't think it's worth adding just for computer 
science playground experiments alone.)

And, FWIW, JSON objects can absolutely be represented in Swift as 
Dictionary. I even typealias that as JSONObject, and have a 
lot of code parsing and producing these. While TreeDictionary 
looks superficially safer, I doubt it's worth the trouble. But again, I'd like 
to be proven wrong; the burden is on you to present the use cases!

I'm appalled by the fascination of Swift community with JSONValue-like enums. 
They produce the most horrible code on the parsing side, and seem to be an 
academic experiment in type safety. See this framework for what I believe to be 
the right approach to dealing with JSON in Swift: 
https://github.com/ExpressiveSwift/ExpressiveCasting

A.

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

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

[Andrey Tarantsov via swift-evolution]

>> I also like the idea of a dedicated method-cascading operator, like what 
>> Dart has.  It eliminates the need for a programmer to explicitly remember to 
>> 'return self' at the end of a chainable method.  Not sure how well it'd 
>> integrate with SE-0047 (@discardableResult) though.
> 
> Method cascades draft: https://gist.github.com/erica/6794d48d917e2084d6ed 
> 
> 
> deferred to after 3.0

I really think this settles the discussion, because methods cascades are *the* 
way to implement this kind of thing. (And for the record, I would prefer a 
SmallTalk/Dart-like syntax to a "with" statement.)

A

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

Re: [swift-evolution] TreeLiteralConvertible

[Andrey Tarantsov via swift-evolution]

Hey, Milos!

Can you please give us a few real-world examples where initializing a 
nontrivial tree-like data structure in code would be useful?

It's an honest question — I have never felt the need in my life, and I always 
preferred to move the data into something like a bundled json or CSV, rather 
than providing it in code.

A.


> On Apr 14, 2016, at 10:27 PM, Milos Rankovic via swift-evolution 
>  wrote:
> 
> In Swift, we cannot compile:
> 
> _ = [[], 1, [2, 3], [[4, 5], [6, 7], [8, 9]]]
> 
> The reason for the compile-time error is that we are not in fact creating an 
> array, but a tree – a more general structure of which arrays are only a 
> special case. Given the well-deserved and growing reputation of Swift, one 
> would hope that in this instance the compiler would be able to default to 
> something like a:
> 
> enum Tree {
>   case Leaf(Value)
>   case Branches([Tree])
> }
> 
> extension Tree : ArrayLiteralConvertible {
>   init(arrayLiteral elements: Tree...) {
>   self = .Branches(elements)
>   }
> }
> 
> For this to work in the playground, however, we must manually lift the values 
> into the world of trees first. And to make that chore in turn easier on the 
> eye we can introduce a:
> 
> prefix operator ◊ {} // looks a bit like a leaf (us/uk kbd: ⎇⇧V)
> prefix func ◊  (leaf: T) -> Tree { return .Leaf(leaf) }
> 
> let tree: Tree = [[], ◊1, [◊2, ◊3], [[◊4, ◊5], [◊6, ◊7], [◊8, ◊9]]]
> 
> The point here is that if adding such a fundamental type to the Standard 
> Library would not be a priority at present, it is not the end of the world 
> since we can easily enough write it ourselves… What we cannot do ourselves, 
> however, is to get rid of the need for that operator in the common scenario 
> of initialising with literal values. For this we need a literal-convertible 
> protocol requiring two initialisers:
> 
> protocol TreeLiteralConvertible {
>   associatedtype LeafValue
>   init(literal: Self.LeafValue...)
>   init(literal: Self...)
> }
> 
> Then we could simply:
> 
> let tree: Tree = [[], 1, [2, 3], [[4, 5], [6, 7], [8, 9]]]
> 
> And, whilst we are at it, we could also get rid of the need for that operator 
> in the case of nested associative arrays (again, you can try this in the 
> playground):
> 
> enum DictionaryTree {
>   case Leaf(Value)
>   case Branches([(Key, DictionaryTree)])
> }
> 
> extension DictionaryTree : DictionaryLiteralConvertible {
>   init(dictionaryLiteral pairs: (Key, DictionaryTree)...) {
>   self = .Branches(pairs)
>   }
> }
> 
> prefix func ◊  (leaf: Value) -> DictionaryTree { 
> return .Leaf(leaf) }
> 
> let map: DictionaryTree = [
>   "A" : [:],
>   "B" : [
>   "Ba" : ◊0,
>   "Bb" : ◊0,
>   "Bc" : [
>   "Bc1" : ◊0,
>   "Bc2" : ◊0,
>   "Bc3" : ◊0
>   ]
>   ]
> ]
> 
> … by introducing an analogous protocol:
> 
> protocol DictionaryTreeLiteralConvertible {
>   associatedtype Key
>   associatedtype LeafValue
>   init(literal: Self.LeafValue...)
>   init(literal: (Key, Self)...)
> }
> 
> Please note: I do understand that fleshing out these structures (along with 
> all the juicy methods, operators and lazy alternatives) may not currently be 
> a priority for Swift. The two literal-convertible protocols however, may be a 
> much less daunting task, which would open to us some very useful programming 
> idioms…
> 
> milos
> ___
> 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] [Pitch] Adding a Self type name shortcut for static member access

[Andrey Tarantsov via swift-evolution]

> My preference would be for there to be only one Self, and have it always be 
> the dynamic type of 'self'. Some people disagree, but I don't think it's all 
> that onerous to have to write ClassName.foo if that's really what you 
> specifically mean.

+1. There's just no way we want to explain two kinds of Selves to people.

However, we need to make sure it works in these contexts:

1) #selector
2) getting an unbound method
3) referring to static methods (including private ones)

A.

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

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

[Andrey Tarantsov via swift-evolution]

> I'd prefer a more general solution instead of introducing the notion of an 
> "optional" function: just make it possible to write default implementations 
> inline in a protocol definition. 

This would work, too. I guess there's no need for an “optional” keyword if the 
implementation is right there in the protocol declaration.

A.

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

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

[Andrey Tarantsov via swift-evolution]

I understand the concern.

To me, the answer is clearly yes. The language cannot be considered in 
isolation from its use cases; imagine UIKit written in Swift.

You want the developers to be able to quickly understand which table view 
delegate methods they need to implement, and what the contract is (are cells 
editable or non-editable by default?).

We need the same thing for our own UIKit-style controls we're writing today 
(and we don't want to be limited to @objc types when doing that — those are 
particularly ill-suited for the return values of optional delegate methods; I 
often want a CGFloat? or a enum).

I don't see this as a separate faculty as much as a shorthand, similar to how 
T? is a shorthand for Optional.

The general opinion on shorthands varies from “there should be exactly one way 
to do everything” Python-style to “the language should help the developer 
express themselves” Ruby/Perl-style.

I personally am firmly in the “Ruby camp” here, so I'm all for use 
case-specific shorthands for general facilities.

You, sir (together with your dream team), should probably pick an official 
stance on this matter. :-)

A.


On 4 Apr 2016 04:15 +0600, Yuval Tal, wrote:
> For readability and specifically in this case, I think it does make sense 
> IMHO.
>  
> On Sunday, April 3, 2016, Chris 
> Lattnerwrote:
> >  
> > > On Apr 3, 2016, at 10:40 AM, Andrey 
> > > Tarantsovwrote:
> > > > Protocol requirements with default (no-op) implementations already 
> > > > satisfy that design goal, no?
> > > Chris, as we've discussed in a thread that I think got forked from this 
> > > one:
> > >  
> > > Yes, they do technically, but it would be nice to both:
> > >  
> > > 1) make it an obvious documented part of the signature, possibly 
> > > including the default return value
> > >  
> > > 2) possibly make it less verbose by getting rid of the explicitly spelled 
> > > out protocol extension
> > Right, but “more is worse” when it comes to language design.Having a "more 
> > general" facility that greatly overlaps with a “more narrow” facility 
> > always makes us question whether it is worth the complexity to have both.
> >  
> > -Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andrey Tarantsov via swift-evolution]

> Protocol requirements with default (no-op) implementations already satisfy 
> that design goal, no?

Chris, as we've discussed in a thread that I think got forked from this one:

Yes, they do technically, but it would be nice to both:

1) make it an obvious documented part of the signature, possibly including the 
default return value

2) possibly make it less verbose by getting rid of the explicitly spelled out 
protocol extension

A.


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

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

[Andrey Tarantsov via swift-evolution]

>> I've actually had multiple cases in Objective-C code where this feature 
>> (some object behaving differently depending on wether or not a delegate 
>> method has been implemented) has prevented me from implementing features the 
>> easy and obvious way. In those cases I resorted to implementing 
>> 'respondsToSelector:'. So I'd argue that optional protocol methods encourage 
>> this type of behavior, which imho is bad API design. If you need to behave 
>> differently for some types of delegates (or whatever else your protocol 
>> represents), a separate method to call to determine how to behave is much 
>> simpler and better to use.
> 
> +1.  This is exactly the same thing I mentioned regarding the fast path for 
> row height in UITableView.  The fact that it depends on whether or not the 
> delegate implements heightForRowAtIndexPath is a bad design decision.

Yes, but please observe that the form of optional methods that we're discussing 
here is limited to avoid the case you mention (I hate that problem as well, 
very very much).

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

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

[Andrey Tarantsov via swift-evolution]

> I do not understand why an optional method should require a default value. 
> That’s not how optional methods work in Objective-C where the caller will ask 
> whether the method is implemented and calls it or does something else. With a 
> default value it would be much more difficult to do something different if 
> the method is not implemented.

Yes, and that's the best part. The way Obj-C optional methods currently work, 
they are very hard to wrap/proxy/etc. Swift has a lot more expressive power, so 
I'm sure that you can adjust the return value to express the “I don't care” 
case without making the absence of the method magical.

A.

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

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

[Andrey Tarantsov via swift-evolution]

> Some ideas I was thinking about for optional protocol functions was you’d 
> declare it like this:
> 
> protocol UIGestureRecognizerDelegate {
>  optional func gestureRecognizerShouldBegin(gestureRecognizer: 
> UIGestureRecognizer) -> Bool = true
> }
> 
> If you put “optional” there, the compiler would auto-generate an empty 
> function in a protocol extension in your module as if you had specified one 
> yourself. If the function has a return value, you would be required to 
> specify the default return value in the protocol which provides automatic 
> documentation of the default, too.

REALLY digging this. Strong +1.

A.

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

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Andrey Tarantsov via swift-evolution]

>> My point is that "protected" *isn't* access control. If we added it, it 
>> would have to be as an independent modifier. Private/internal/public 
>> fundamentally affect semantics—private and internal code is only accessible 
>> within a module, so we have full knowledge of their use sites at compile 
>> time and can be more permissive with extensions, implicit constructors, and 
>> other features. Public API can be used by arbitrary unknown external code so 
>> requires additional restrictions to ensure that the interface remains 
>> stable. "Only usable by subclasses" is an orthogonal axis to this—if a 
>> method is only usable by external subclasses, it requires all of the same 
>> restrictions as public code. If a method is only usable by subclasses within 
>> the module, it can behave like a private or internal method.

Okay. So you see it as “public subclassonly”, leaving space for “internal 
subclassonly” (which makes sense, although not as important in practice).

I can agree with that, let's consider it a new strawman.

I wonder, though, if you guys have additional, fresh ideas on the underlying 
problem. We're not really limiting to subclasses here — we're limiting to 
“extenders” aka “service providers”, and those don't necessarily take a form of 
a subclass. I've listed some examples in my strawman: an implementation of a 
protocol, an extension of a class/protocol.

Are there any novel and fresh ideas that would take care of all that in a 
straightforward and uncomplicated way?

A.

___
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

[Andrey Tarantsov via swift-evolution]

> public
> filewide 
> modulewide 
> private
> 
> Don’t bother me because they seem to be part of the word. The way 
> “nationwide” does, they are made up words but intent is clear.

I could live with filewide and modulewide instead of fileprivate and 
moduleprivate.

I still prefer the latter ones, but I wonder if -wide ones will be a happier 
compromise? Those unhappy with xxxprivate, please speak up!

A.

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

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

[Andrey Tarantsov via swift-evolution]

> I personally like it because I consider the defaulted parameters to be “extra 
> add-ons” or the alternative to a “userInfo: [String: AnyObject]” pattern.
> 
> I’d vote to leave things as-is unless it imposes a significant maintenance 
> cost on the compiler.

Strong +1. Please leave it be, it's a useful feature in a small but important 
subset of cases.

A.

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

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Andrey Tarantsov via swift-evolution]

> The problem with protected is that it provides virtually no protection at 
> all; you can trivially expose it in a derived class

+

> Extensions further dilute the enforceability of "protected", since anyone 
> would be able to use an extension to dump methods into a class's namespace 
> and access its supposedly-protected bits.

I don't understand the need to protect against exposing something deliberately. 
We don't have a goal of restricting other developers, we're only saving them 
from accidental mistakes.


> If a method was marked private in the base class, then it is very likely that 
> the name of the method, the design of its argument list and its return value 
> did not go through the same detailed design review as if the method would 
> have been meant to be part of the class’ interface from the start. So it’s 
> rather unlikely that increasing the visibility in an override is good idea 
> and in the spirit of the original writer of the private method.

The design review and whether something is a good idea is left as a 
responsibility for those subclasses that choose to expose methods. The 
intentions of the original class author don't override the intentions of the 
subclass author.


That said, I don't necessarily believe that the protected modifier is the best 
solution for the problems we're discussing. Some methods are not intended to be 
called at all, and protected doesn't solve that.

A.

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

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

[Andrey Tarantsov via swift-evolution]

I'm missing those optional methods too, but protocol extensions sound like a 
better solution for this.

(For those suggesting a separate protocol, consider UITableView. How many 
protocols would it take to model all the optional delegate methods as separate 
protocols? Certainly more than 10, perhaps a few dozen.)

I would welcome a standardized way to document the methods as 
optional-to-implement, though, beyond just requiring a protocol extension. My 
ideal option would be to allow the optional keyword and change it to simply 
require a default implementation in a protocol extension.

If we don't want a language change, then perhaps a conventional doc tag?

A.


> On Mar 30, 2016, at 8:08 PM, Yuval Tal via swift-evolution 
>  wrote:
> 
> Hi,
> 
> I find that optional protocol methods to be very useful. However, there is a 
> caveat -- it needs to be mapped to @objc. This puts a set of limitations, 
> such as: structures cannot be used as parameters as it does not map to 
> objective-c. What do you think about removing the requirement of using @objc 
> and allow to create optional methods without these limitations?
> 
> Thank you,
> 
> -Yuval
> ___
> 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] Hidden initiallizations ...

[Andrey Tarantsov via swift-evolution]

> Actually I use a lot of Applescript style naming, though admittedly I can be 
> a bit inconsistent about it. For example, I like using eachFoo as a name for 
> a loop variable like so:
> 
>   for eachIndex in 1 ..< 100 { … }
> 
> Which can read nicely as natural language, but since I don’t use eachFoo 
> anywhere else, helps to avoid name collisions. If eachFoo is optional, then I 
> might unwrap the value into theFoo instead like-so:
> 
>   let theValues:[Int?] = []
>   for eachValue in theValues {
>   if let theValue = eachValue { /* Do some stuff */ }
>   else { /* Do some other stuff */ }
>   }

Interesting! :-) I should explore this, sounds fun in some cases.

I typically just use the bare word:

for value in values {
  if let value = value {
foo(value)
  }
}

...but sometimes that clashes with an argument or field, and yours could be a 
good convention to resolve those cases.

A.

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

Re: [swift-evolution] Hidden initiallizations ...

[Andrey Tarantsov via swift-evolution]

This is idiomatic Swift. I see no readability issues with that.

Of course, shadowing a local var with a for loop counter is another case. I'd 
say a warning is warranted there.

A.


> On Mar 29, 2016, at 5:30 PM, Biala  wrote:
> 
> And you are OK with that 
> I can not imagine my team writing such code and me looking to 5 code reviews 
> per day having to find out what the variable actually is every time :)
> 
> For me it is OK for student projects but not for big code that have to be 
> supported for years ...
> 
> 
> On Tuesday, March 29, 2016 2:02 PM, Andrey Tarantsov  
> wrote:
> 
> 
>> Having more that one variable with the same name in one method is stupid and 
>> the language should prevent that at least. 
> 
> Actually, we're doing it all the time:
> 
> if let foo = foo {
>   ...
> }
> 
> var foo = foo
> 
> You can do this in a subscope, you can do this to the arguments, and you can 
> do this to fields.
> 
> A.
> 
> 
> 

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

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

[Andrey Tarantsov via swift-evolution]

> My understanding is that this comes about from a simple idea - someone wants 
> to have objects which have some protection of their API from the outside 
> world, and to limit the interface between those objects from exposing 
> internal implementation details in order to maintain invariance.

No, this comes from the desire to document the specific members that are 
accessed by other scopes in the file.

I think it makes a significant difference when reading code.

A.

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

Re: [swift-evolution] [Review] SE-0026 Abstract classes and methods

[Andrey Tarantsov via swift-evolution]

> This should be resolved when PwS  
> (Protocol with 
> Storage) get alive:
> 
>   // Framework land
> public protocol DatabaseRecord {
>   internal extension DatabaseRecord {
> var referenceRow: DatabaseRow
>public  extension DatabaseRecord {

Yay for visibility and storage in protocols, and generally for being able to 
provide a different API to the implementers of the protocol compared to the 
clients of the protocol.

But.

> So explain to me: if this code worked:
> 
>   protocol ActivityViewControlling: UIViewController {
>   func retrieveText() -> String
>   }
>   extension ActivityViewControlling {
>   @IBOutlet var messageLabel: UILabel!
>   
>   override func viewWillAppear(animated: Bool) {
>   super.viewWillAppear(animated)
>   messageLabel.text = retrieveText()
>   }
>   }
> 
> What would you feel was missing compared to this?
> 
>   abstract class ActivityViewController: UIViewController {
>   abstract func retrieveText() -> String
>   
>   @IBOutlet var messageLabel: UILabel!
>   
>   override func viewWillAppear(animated: Bool) {
>   super.viewWillAppear(animated)
>   messageLabel.text = retrieveText()
>   }
>   }

For all intents and purposes, you made an abstract class here, but calling it a 
protocol. 

It has advantages:

+ you can achieve multiple inheritance that way
+ ... hm? what else?

and disadvantages:

+ it's still, for all intents and purposes, an abstract class, but for some 
reason you're now calling it a protocol — THAT'S confusing, if you ask me;  now 
there's two kinds of protocols, the normal ones and the ones that do magic 
stuff when you implement them (I personally think those latter thingies should 
be called mixins)
+ it has additional limitations (I don't think you can call super, which is 
often very useful)
+ it's a concept that doesn't work or exist, and there's no telling if it'll be 
a part of Swift 3 or not

I believe we're confusing conceptual and implementation details here. 
Conceptually, both approaches seem to be using two different names for the same 
thing; I don't really care if the functionality I need comes through a 
supercharged protocol or a slightly enhanced class.

Are we really discussing anything more than a name? If yes, what is it?

Implementation-wise, the compiler can always translate abstract classes into 
protocols internally, so I don't really see the implementation difference as 
important.

A.

___
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

[Andrey Tarantsov via swift-evolution]

> Sure, but is that worth 7 to 9 extra characters at every single use site for 
> something that's actually pretty common?

Yes.

These are special cases — both file-private and module-private is something 
that is fairly unusual and should stick out a bit, so the length helps here. 
(Unless you're writing your entire app in module-private mode, in which case 
you won't use the modifier at all.)

I think Chris has explicitly stated that brevity for the sake of typing less is 
not a goal of Swift. There's software like Keyboard Maestro that I really 
recommend when typing code; just assign keyboard shortcuts (GW-BASIC-style) to 
the common keywords, and the length won't matter. 

> We call the type `Int32`, not 
> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`

Perhaps the new modifiers look worse to you than to me. "fileprivate var" reads 
just fine to my ears, exactly the right balance of length and brevity, and 
"file var" invokes wrong associations in my head, akin to being a static var, 
and generally feels way too short.

A.

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

Re: [swift-evolution] Rewrite imported C function signatures

[Andrey Tarantsov via swift-evolution]

Reposting my comment from that other thread:

[...] it's more of an external annotation on C code, something that we don't 
currently support for user code. (My understanding is that they have it 
implemented for Apple frameworks.) Perhaps, with Swift 3 going Linux, with 
should expose the ability to annotate external code to the users? And enum 
importing could be a part of that.

A.

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

Re: [swift-evolution] Promote "primitive" types to enums in extensions

[Andrey Tarantsov via swift-evolution]

> I think I may be similarly misunderstanding your proposal; your intention 
> then is to import the type as an enum with raw value (to facilitate the 
> conversion to/from the C code) but without exposing that raw value on the 
> Swift side?
> 
> In that case I think I’m in favour.

Me too.

But perhaps not through the originally proposed syntax. I don't think this is 
an extension — it's more of an external annotation on C code, something that we 
don't currently support for user code. (My understanding is that they have it 
implemented for Apple frameworks.)

Perhaps, with Swift 3 going Linux, with should expose the ability to annotate 
external code to the users? And enum importing could be a part of that.

A.


___
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

[Andrey Tarantsov via swift-evolution]

> Why is it important to highlight word boundaries in so many other conventions 
> in Swift but not in this one? What would be lost with this alternative?
> 
> public
> module_private
> file_private
> private
> 
> Is it just the extra (chorded, on US keyboards) keystroke? I think the 
> readability benefits of clear word boundaries far outweigh the keystroke cost 
> (especially with good editor auto-complete).

The keywords, unlike identifiers, are always the same. You don't need to parse 
them every time; ‘on an infinite timescale’, you get used to them and recognize 
them at a glance. So the value of adding an underscore (or, heaven forbid, 
camel case style) to a keyword is a lot less than with identifiers.

My personal completely subjective opinion is that the underscored ones look 
gross and pull too much attention onto themselves, rather than helping to focus 
on the identifiers. To me, this actually detracts from the overall readability 
of the entire line.

In other words: nothing says “nothing to see here, move along” quite like 
abunchofgibberishthrowntogether.

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

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

[Andrey Tarantsov via swift-evolution]

>> The new default is better for:
>> 
>> - (A) classes that provide both mutating and non-mutating methods;
>> - (B) methods where forgetting to use the result produces a bug (a
>> download task that needs to be resumed, an alert that needs to be
>> displayed, a listener that needs to be stored somewhere, etc).
> 
> To be clear, the mistake this warning prevents is the unintentional call
> to a non-mutating method when one thinks one is mutating the receiver.
> This scenario can arise independently of A or B.

Sure. Although if a type only has mutating or non-mutating methods, but not 
both, the mistake will probably be immediately apparent, so the diagnostic 
doesn't win you much (except maybe in a newbie learning environment, which is 
an important use case as well).

A.

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

Re: [swift-evolution] Deprecating Trailing Closures

[Andrey Tarantsov via swift-evolution]

> I use trailing closures all the time because I find the brackets too noisy, 
> like ; at the end of a line is too noisy. The sort of code I use is:
> 
> let foo = myArray
> .filter { $0 & 1 == 1 }
> .map { $0 + 1 }
> .reduce(0) { $0 + $1 } 

+1 to this. Please don't remove them, they're great.

A.

___
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

[Andrey Tarantsov via swift-evolution]

Coming in late, but:

* “internal”, as already mentioned, has prior art as meaning “private to a 
package/project”, so should stay as it is
* fileprivate looks good, obvious, straightforward and googlable to me
* private(file) introduces a bunch of visual noise that I don't like
* whoo-hoo, this discussion is impossible to read through — the power of 
bike-shedding!

A.


> On Mar 18, 2016, at 7:46 PM, Ilya Belenkiy via swift-evolution 
>  wrote:
> 
> It looks like people finished the discussion for the best access level names. 
> How should I update the proposal?
> 
> On Mon, Mar 14, 2016 at 8:18 PM Chris Lattner via swift-evolution 
> > wrote:
> Per Doug’s email, the core team agrees we should make a change here, but 
> would like some bikeshedding to happen on the replacement name for private.
> 
> To summarize the place we’d like to end up:
> 
> - “public” -> symbol visible outside the current module.
> - “internal” -> symbol visible within the current module.
> - unknown -> symbol visible within the current file.
> - “private” -> symbol visible within the current declaration (class, 
> extension, etc).
> 
> The rationale here is that this aligns Swift with common art seen in other 
> languages, and that many people using private today don’t *want* visibility 
> out of their current declaration.  It also encourages “extension oriented 
> programming”, at least it will when some of the other restrictions on 
> extensions are lifted.  We discussed dropping the third one entirely, but 
> think it *is* a useful and important level of access control, and when/if we 
> ever get the ability to write unit tests inside of the file that defines the 
> functionality, they will be a nicer solution to @testable.
> 
> The thing we need to know is what the spelling should be for the third one.  
> Off hand, perhaps:
> 
> fileprivate
> private(file)
> internal(file)
> fileaccessible
> etc
> 
> Some other thoughts on the choice:
> - this will be a declaration modifier, so it will not “burn” a keyword.
> - if will be a uniquely Swift thing, so there is virtue in it being a 
> googlable keyword.
> 
> Thoughts appreciated.
> 
> -Chris
> 
> ___
> 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

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

Re: [swift-evolution] struct subtyping

[Andrey Tarantsov via swift-evolution]

+1, would love this.

A.

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

Re: [swift-evolution] Alternate proposal for multi-line string literial

[Andrey Tarantsov via swift-evolution]

Feels wrong to me. It's ugly (looks like line noise) and unnecessary (this much 
flexibility isn't required in practice). Making features more powerful doesn't 
always make them better.

Some of the use cases you have in mind are probably better handled by macros, 
whenever they make it into Swift. Macros provide a general and elegant way to 
handle customizable special cases without introducing an unusual complicated 
syntax for each of them.

So, nope, sorry, let's stick to making tripe-quote multiline strings as awesome 
as possible, but not awesomer. :D

A.




> On Mar 23, 2016, at 10:49 AM, Steve K. Chiu via swift-evolution 
>  wrote:
> 
> Hi,
> 
> I am new to swift-evolution list, here is my draft proposal for the 
> multi-line string literal problem.
> The idea had been discussed in the list before, but it seems there are no 
> real solution to many of the string literal problem.
> Let's first define what are the problem with string literal:
> 
> 1. should be able to disable escape char
> 
> 2. or better, able to replace escape char with user defined char
> 
> 3. should be able to write multi-line string literal, and is copy-paste 
> friendly
> 
> 4. for multi-line string, should be  able to remove first and last newline 
> char, so user can write string in block
> 
> 5. for multi-line string, should be  able to remove leading indent, or remove 
> all indent
> 
> 6. for multi-line string, should be  able to replace newline with user 
> defined string ("\r\n", "\r", "\r", or simply " ")
> 
> 7. should be able to add feature over time, without breaking existing code
> 
> My proposal to the above problem is to introduce new 'process instruction' 
> (not sure how to call it), in the following form:
> 
> #string(options) "text"
> 
> for example:
> 
> #string(escape: nil) "^\d+"
> 
> #string(escape: "$", end: "") "
>$(username),
>Is it 1358 yet?
> "
> 
> It is possible to add many options list above, and you can add more options 
> over time without breaking code.
> 
> #string(
> escape: Character? = "\\",
> end: String? = nil,   
> skipEnclosureNewline: Bool = true,
> skipLeadingIndent: Bool = true, 
> skipAllIndent: Bool = false,
> newline: String? = nil
> )
> 
> for 1. & 2., escape option to replace escape char, pass nil will disable 
> escape.
> 
> for 3., end option for end-of-string mark, pass nil will disable multi-line 
> processing.
> 
> for 4., skipEnclosureNewline will skip newline if it is the first or last 
> char of the string.
> 
> for 5., skipLeadingIndent will skip leading indent, leading indent is the 
> leading white-spaces of first line of multi-line string.
> 
> for 5., skipAllIndent will skip all indent, this will override 
> skipLeadingIndent.
> 
> for 6., newline option to replace newline char in multi-line string, pass nil 
> will disable the replacement (as-is in the source).
> 
> But there are one problem remain, as you can see, the #string with options 
> will become very long; I don't think it is a pleasure to use such expression 
> except for one time literal. To fix the problem, I propose yet another 
> process instruction:
> 
> #let #rex = #string(escape: nil)
> #let #mail = #string(escape: "$", end: "")
> 
> Now you can write the string as:
> 
> #rex "^\d+"
> 
> #mail "
>$(username),
>Is it 1358 yet?
> "
> 
> #let should be able to be used with other # process instruction as well, for 
> example, #available, among other things.
> 
> What do you think?
> 
> 
> ___
> 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] [Idea] Find alternatives to `switch self`

[Andrey Tarantsov via swift-evolution]

Honestly, we really need this for a lot of different cases:

> * Allow you to attach member definitions to particular cases. It would be an 
> error if they didn't all define the same members, unless there was a 
> top-level catchall.
> 
>enum Suit: Int {
>var isRed: Bool { return false }
> 
>case Hearts {
>let description: String { return "♥️" }
>let isRed: Bool { return true }
>}
>case Spades {
>let description: String { return  "♠️" }
>}
>case Diamonds {
>let description: String { return  "♦️" }
>let isRed: Bool { return true }
>}
>case Clubs {
>let description: String { return  "♣️" }
>}
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>}

A.

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

Re: [swift-evolution] [Draft] Adding a Build Configuration Import Test

[Andrey Tarantsov via swift-evolution]

Strong +1, very useful.

Perhaps importable instead of canImport? Looks and reads better:

// UXKit at WWDC'16, pretty please!
#if importable(UIKit)
typealias UXColor = UIColor
#elseif importable(Cocoa)
typealias UXColor = NSColor
#else
// meh
#endif

A.

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

Re: [swift-evolution] idea: immutable setters for structs and tuples?

[Andrey Tarantsov via swift-evolution]

> I would very much like a standardized way of doing this.

+1 for a function like with/lens in stdlib.

A.

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

Re: [swift-evolution] [Pitch] Change the endIndex value for closed Ranges and Collections

[Andrey Tarantsov via swift-evolution]

PS:

> endIndex is exclusive by definition

If you want a rationale on this...

1) It's how cursors typically work, and people familiar with the concept 
already expect this.

2) It's often the most convenient choice. Back in the day, you would write C 
code like this:

for (int *cur = array, *end = array + size; cur < end; ++cur) {
process(*cur);
}

Similarly, you can compute the number of elements by just getting the 
distance between startIndex and endIndex (or end - cur in the C example above).

Making the upper boundary inclusive would require explicit '- 1' and '+ 1' 
in quite a few places, which is ugly and unnecessary.

3) The upper bound is almost always excluded in programming, in many unrelated 
APIs (e.g. arc4random_uniform), so it's a good default choice.

A.

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

Re: [swift-evolution] [Pitch] Change the endIndex value for closed Ranges and Collections

[Andrey Tarantsov via swift-evolution]

Pedro,

endIndex is exclusive by definition. You can iterate over any collection by 
going from startIndex until you reach endIndex.

If we change endIndex on ranges, *all* generic iteration code will be broken 
when dealing with ranges, even the for statement.


I understand that there are two concerns here:

1) The desire to keep the semantics of 1...10 intact, so that you can access 
that 10 somehow (perhaps something like lastValidIndex?), the description 
returns the expected value, etc. To achieve this, a different class 
(ClosedRange) would probably make more sense, because there's no need to make 
this decision at runtime.

2) The desire to change endIndex specifically. This is a no-go.

A.

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

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

[Andrey Tarantsov via swift-evolution]

+1, but

> Expand the scope of “if” and “while” statements

+2 for this. At least a dozen times I've been beaten by changing

let foo = bar.map { ...} 

into

if let foo = bar.map { ...} {
...
}

only to find myself with a compiler error (because my brain just doesn't 
register this transformation as invalid).

I would be fine with limiting such a call to a single line, because a multiline 
scenario looks crazy anyway. I would also be fine with disallowing single-line 
IFs in this case, because, again, they look crazy. Those two limitations would 
allow unambiguous parsing in all cases.

And yay for unbounded lookahead and heroics. We should use all that RAM and 
CPUs for something, after all.

A.

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

Re: [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it

[Andrey Tarantsov via swift-evolution]

Just thinking out loud — ‘dynamic’ as an attribute on an object, allowing 
arbitrary method calls that are dispatched dynamically...

let foo: @dynamic AnyObject = Foo()
foo.someWeirdMethod()

for thing in things {
(thing as @dynamic).bar()
}

Dynamic as a type:

let foo: dynamic = Foo()
foo.someWeirdMethod()

for thing in things {
(thing as dynamic).bar()
}

Since the dynamic keyword defines a function that goes through runtime 
dispatch, the same very runtime dispatch that current AnyObject calls go 
through, it would make sense for the new stuff to be called something like 
dynamic or dynamic_binding or DynamicObject or whatever.

A.

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

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

[Andrey Tarantsov via swift-evolution]

> What is your evaluation of the proposal?

-0.5 if the annotation is verbose (much longer than @discardable).
+0.5 if the annotation is pleasant and concise, like @discardable

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

The warn-by-default behavior is mostly useless. The only reason to make the 
change is because “if we were designing Swift from scratch, this would probably 
be a slightly better default”.

Most non-void functions are called for their result, and nobody ever forgets to 
use that result; if they do, it's like if they forgot to call the function 
altogether — trivial to find, not useful as a compiler diagnostic at all.

The new default is better for:

- (A) classes that provide both mutating and non-mutating methods;
- (B) methods where forgetting to use the result produces a bug (a download 
task that needs to be resumed, an alert that needs to be displayed, a listener 
that needs to be stored somewhere, etc).

The old default is better for:

- (C) fluid APIs and other similar DSL scenarios;
- (D) methods that are mainly invoked for their side effect and return a value 
“just in case”, like removing/adding elements, scheduling tasks, ...

I've just scanned the entire Swift codebase I wrote since that fateful WWDC'14 
(~20 kLOC excluding comments and blanks). I only have a handful of 
classes/methods in each category above, and annotating them one way or another 
is a trivial matter. Some of them *are not* currently annotated with 
@warn_unused_result, which is a point in favor of this proposal.


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

I think the safe-by-default, explicit-opt-out behavior is a better default for 
Swift, although, like I've said, in practice it doesn't really matter much.

Perhaps it's most useful for newcomers; you can easily skip over 
@warn_unused_result when learning Swift, but you won't be able ignore 
@discardable.


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

Haven't ever seen this in a language.

Golang had a (not very informative) discussion on this topic at 
https://groups.google.com/forum/#!topic/golang-nuts/ksfgSWxJcCo


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

Closer to an in-depth study; looked at my Swift codebase, and read through all 
the discussions.

On a side note, let me once again point to a dangerous trend in this mailing 
list: not looking at (or reporting on) how potential changes affect actual, 
specific, production code bases. We need a lot more of that in our reviews.

Thanks,

A.

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

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

[Andrey Tarantsov via swift-evolution]

I have no stake in this proposal, except for:

> I suggest, therefore, that this acceptance be indicated by
> an annotation to the literal; a form such as ~0.1 might be easiest to
> read and implement, as the prefix ~ operator currently has no meaning
> for a floating-point value.

Whatever you do, don't touch the literals! I specify NSTimeIntervals of 0.1, 
0.2, 0.25 etc all over the place, and I couldn't care less if my animations are 
one femtosecond off.

Don't pollute everyone's apps with tildes just because there's a niche that 
needs to care about precision loss.

A.

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

Re: [swift-evolution] Add an ifPresent function to Optional

[Andrey Tarantsov via swift-evolution]

> No.  My argument is that map on collections and on optionals are two
> completely different things.  They unify on a level that does not
> exist in Swift (higher-kinded types).

+1000.

Optional.map is already highly unfortunate. It makes optional arrays especially 
painful to deal with, but even in general, you can no longer glance at the code 
and see which parts are dealing with many items and which parts are dealing 
with single items.

I would definitely support renaming Optional.{map,flatMap}.

A.

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

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Andrey Tarantsov via swift-evolution]

I'm against this, because I often write extensions on Apple classes (like, say, 
UIColor) that are only intended to be used from Swift, in a pure-Swift project, 
and I need no stinking' @nonobjc in there.

How much of a problem can this surprise be? You call a method, the compiler 
tells you it's not there, you look up the reason, no harm done.

A.



> On Jan 5, 2016, at 11:32 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> We currently have a bit of a surprise when one extends an @objc protocol:
> 
> @objc protocol P { }
> 
> extension P {
>   func bar() { }
> }
> 
> class C : NSObject { }
> 
> let c = C()
> print(c.respondsToSelector("bar")) // prints "false"
> 
> because the members of the extension are not exposed to the Objective-C 
> runtime. 
> 
> There is no direct way to implement Objective-C entry points for protocol 
> extensions. One would effectively have to install a category on every 
> Objective-C root class [*] with the default implementation or somehow 
> intercept all of the operations that might involve that selector. 
> 
> Alternately, and more simply, we could require @nonobjc on members of @objc 
> protocol extensions, as an explicit indicator that the member is not exposed 
> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
> mechanism and motivation to make default implementations of @objc protocol 
> extension members work, we could easily remove the restriction at that time.
> 
>   - Doug
> 
> [*] Assuming you can enumerate them, although NSObject and the hidden 
> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
> root class itself might default such a method, and the category version would 
> conflict with it, so...
> 
> ___
> 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] Final by default for classes and methods

[Andrey Tarantsov via swift-evolution]

> Isn't this proposal solving a problem that in practice doesn't exist or isn't 
> common enough to be worth a language level fix?

Well I have a TextExpander macro that inserts "// override point" when I type 
;overp. Been marking all overridable methods this way for years. I think it's 
an indication that the problem is worth solving.

> I'm trying to find an example of a common problem - in any language - that 
> would benefit by having final/sealed by default.

Understanding the code and reasoning about the class is easier when you know 
the exact customization points.

I do agree that this won't really prevent many actual bugs.

A.

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

Re: [swift-evolution] Final by default for classes and methods

[Andrey Tarantsov via swift-evolution]

> Aren't we mixing up two different issues here? "Having a default final for 
> Swift classes" should be treated as a separate issue from "Apple frameworks 
> should stay overridable".

I have to agree, and so I'll change my vote to +1.

>  1. Within a module, should I be able to override my own classes / methods by 
> default, or should I have to explicitly mark those classes as overridable to 
> do that?

Definitely not — explicit is preferred, mostly for documentation purposes (I 
don't think there's much safety to be gained within your own module). Perhaps 
because in my code, overridable methods are perhaps 1% of all.

>  2. If I'm releasing a Swift binary framework, and I haven't yet thought 
> about which classes / methods should be overrideable, should I release it in 
>  everything-is-overridable mode, or in nothing-is-overridable mode?

That's a tricky one. Ideally you would pretend that nothing is overridable, but 
some hack like @testable makes everything overridable when really needed.

>  3. If I'm using a third-party (non-Apple) Swift binary framework, and if the 
> framework author hadn't really thought about which classes / methods should 
> be overrideable, would I want the power to override everything in the 
> framework now?

Yes. There were many cases where fixing up a pod was just an important as 
fixing up an Apple framework.

Yes, I have an option to change the source — but it's vastly more 
labour-intensive if all you need is a simple isolated change. (Especially if 
that change isn't likely to be accepted upstream.)

> (Note that if I get that power, I forgo all hope of getting a 
> binary-compatible update to the framework with correct annotations about 
> which classes can be safely overridden and which aren't meant to be 
> overridden.)

Sure, and that doesn't matter because all frameworks are built with your app 
anyway.

>  A3: Ideally, I'd like to be able to override everything in the framework I 
> use, but if that implies that I can't get a binary-compatible fix to the 
> framework, maybe I can live without that overridability.

Why would you want binary compatibility for non-Apple frameworks? It's not like 
you can install them globally (or would want to, even if you could).

A.

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

Re: [swift-evolution] Lambda function syntax

[Andrey Tarantsov via swift-evolution]

One thing I'm really bothered by in C# and ES6 are no-argument methods:

() => { foo() }   // GROSS

The syntax of C# isn't so bad, though, when there's no return type:

foo.map((bar) => bar.boz)

but those double-parens bother me and my eyes a bit, so this definitely looks 
better:

foo.map { (bar) => bar.boz }

I think I'd even prefer that to:

foo.map { (bar) in bar.boz }


What if we just agreed to replace "in" with "=>"? Would that be an improvement 
in your eyes? I could stand behind that proposal.

(btw Chris & team — THANK YOU for the Ruby-style trailing closure syntax, it 
was such a treat to see it last summer!)

A.


> On Dec 23, 2015, at 8:33 AM, Alexander Regueiro  wrote:
> 
> This was my first proposal, and was changed my second, but this syntax is 
> inspired by C#, where a lambda expression is of one of the following forms:
> 
> (Type1 param1, …) => foo // single-statement expression
> (Type1 param1, …) => { …; return foo; } // multi-statement expression
> 
> Haskell also uses syntax closer to this than to Swift, not to mention ML/F#.
> 
>> On 23 Dec 2015, at 02:30, Andrey Tarantsov  wrote:
>> 
>> So I believe the opinion of the core team and the community would be 
>> generally in opposition to the style you want. I understand your arguments, 
>> but somehow they are against the entire experience of me (and, presumably, 
>> others) as developers.
>> 
>> To continue our friendly banter, though, do you mind sharing your 
>> background? When I read this, I wasn't sure if you're serious or trolling:
>> 
>>> I would propose changing it from:
>>> 
>>> { (param_list) -> return_type in … }
>>> 
>>> to something cleaner like:
>>> 
>>> (param_list) -> return_type => { … }
>> 
>> I wonder if doing something like Haskel a lot makes you more used to that 
>> sort of arrow constructs?
>> 
>> This is written in good faith; I hope I used the right tone to indicate that.
>> 
>> A.
>> 
> 

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

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Andrey Tarantsov via swift-evolution]

> I don’t see how this:
> 
> protocol P {
>   type/*alias*/ A
> }
> 
> struct X : P {
>   struct A {}
> }
> 
> is fundamentally any different from:
> 
> protocol P {
>   func f()
> }
> 
> struct X : P {
>   func f() {}
> }
> 
> What am I missing?

I'd say it's the fact that adding an associated type turns a protocol into a 
frankenprotocol, and we don't want that to be cast upon innocent souls without 
a proper curse word (like "associatedtype").

Also, maybe some day we'll have normal type requirements — something that has 
to be defined in a protocol, but does not turn it into a frankenprotocol than 
nobody can use anymore. That would be an appropriate use of the normal-looking 
keywords.

A.

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

Re: [swift-evolution] Brace syntax

[Andrey Tarantsov via swift-evolution]

> I don't know many people who have experienced a large variety (8+?) of 
> programming languages and prefer Python's forced indentation

Count me as one. I'd prefer Swift to have Python-style indentation, just on the 
grounds of braces being stupid (why would you want to enter the same scope 
information twice)?

So +1 from me, although I don't suffer from the braces at all.

I do want to point out that the amount of code that fits on a screen is fairly 
important, and you should keep your methods short, so one less brace per method 
means a couple more methods per screen.

This would also free up braces to mean “closure” in 100% of cases, which is 
good for consistency.

But it would introduce it's share of problems for sure, so I don't feel 
strongly about this proposal.

I also admit that braces are generally preferred, for some mysterious reason 
that I hope a believer can articulate here. Take Sass, for example; it has both 
an indentation-based syntax and a braces-based syntax, and the latter one seems 
way more popular.

A.

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

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

[Andrey Tarantsov via swift-evolution]

> My experience with other languages is that [...] unless you're a Boost 
> maintainer, people tend to target one version of the language anyway, either 
> the older one using a workaround portable to the newer version, or the new 
> version without regards to people stuck behind.

That's not how it works with Apple. Every summer we get a new beta version of 
Xcode with a new version of Swift, which we should use for all new developments 
(because it'll become the shipping version in the fall), but we have to use an 
older one for App Store-ready products if we want to be able to submit updates. 
So libraries do often support several versions of the language.

Just look the libraries that still support dual ARC/non-ARC modes, which is 
something that's not necessary at all.

A.

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