Re: [swift-evolution] commas optional

[Josh Parmenter via swift-evolution]

On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
> wrote:

a semicolon is a purely syntactic delimiter, the comma on the other hand 
corresponds to physical elements in a collection. I think the two are more 
different than you suggest.


I very much agree^

Josh



Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2211 5th Ave Suite 201
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Idea: using 'super()' as syntactic sugar for 'super.overriddenmethod(...)'?

[Josh Parmenter via swift-evolution]

To me, that looks like you are calling init on super.
Best
Josh

Sent from my iPhone

On Sep 26, 2017, at 17:03, William Shipley via swift-evolution 
> wrote:

In cases like this:

override func loadView() {
super.loadView()
view.addSubview(segmentedControl)
segmentedControl.translatesAutoresizingMaskIntoConstraints = false
segmentedControl.centerXAnchor.constraint(equalTo: 
view.centerXAnchor).isActive = true
}

or

override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
if let destinationController = segue.destinationController as? 
ScaleViewController {
scaleViewController = destinationController
destinationController.scalable = self // weak back-link
}
super.prepare(for: segue, sender: sender)
}

We obviously need the ability to manually place the call to 'super' in our 
overridden methods, so we can't just have the compiler always automatically 
call super (like it does with dealloc).

But only occasionally do we need to pass in different parameters to the 
superclass method than were passed into us, and it'd be nice to ? not have to 
do all the extra typing / reading in the common case, ? makes it clear at a 
glance we're calling the _same_ method on our superclass, not accidentally 
calling a different one, and ? make it especially noticeable when we ARE 
changing the parameters around to our call to super by having that be the only 
version where you need to specify them.

So, for instance, the above two methods would turn into:

override func loadView() {
super()
view.addSubview(segmentedControl)
segmentedControl.translatesAutoresizingMaskIntoConstraints = false
segmentedControl.centerXAnchor.constraint(equalTo: 
view.centerXAnchor).isActive = true
}

or

override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
if let destinationController = segue.destinationController as? 
ScaleViewController {
scaleViewController = destinationController
destinationController.scalable = self // weak back-link
}
super()
}

But this contrived example would stay the same:

override public func mouseDown(with event: NSEvent) {
let someOtherEvent = ...
super.mouseDown(with: someOtherEvent)
}

Note that I just made up a contrived example here because I couldn't find a 
single real-world case in my 33,098 lines of Swift code where I call 
super.blah(...) with different parameters than the ones that were passed in, 
which I think also points to why this syntactic sugar is sweet and low-cal. 
(The only time I saw super being called with different parameters was in init() 
methods, where I was calling a different initializer.)

-

Another version would be to use a new word instead of "super()", which doesn't 
overload the noun-ish-ness of 'super':

overridden()
or
superfunc()


It's possible that the empty parenthesis in "super()" would confuse readers 
into thinking some other version of their function is being called (that has no 
parameters), so it's worth considering if something like "overridden" by itself 
(no ()) would be better. I think if this is a worry I'd prefer to use three 
dots to indicate more stuff is going on here, to match with our documentation:

super(...)
or
overridden(...)

An orthogonal idea is for the contrived example would be to allow new 
parameters to be passed in directly without typing the function name again:

super(with: someOtherEvent)
or
overridden(with: someOtherEvent)


-Wil


___
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 safety to arrays

[Josh Parmenter via swift-evolution]

This seems inconsistent to me. 2 is 2... 2 itself is not optional. You wouldn't 
expect 2 to be unwrapped.
Best
Josh

Sent from my iPhone

On Apr 13, 2017, at 08:48, Jeff Kelley via swift-evolution 
> wrote:

Apologies if this has been suggested before, but going off of Andrew's message, 
a simple syntax could be to use our existing Optional syntax:

let array = ["foo", "bar", "baz"]

let first = array[0] // type is `String`
let third = array[2?] // type is `String?`, value is .some("baz")
let fourth = array[3?] // type is `String?`, value is .none

Jeff Kelley

slauncha...@gmail.com | 
@SlaunchaMan | 
jeffkelley.org

On Apr 13, 2017, at 8:19 AM, David Sweeris via swift-evolution 
> wrote:


On Apr 13, 2017, at 3:56 AM, Andrew Hart via swift-evolution 
> wrote:

Recently I've been considering the lack of safety around array indexes. Swift 
is designed with safety in mind, so this example would not compile:

var myString: String? = "hello"
myString.append(" world!")

The string is optional, not guaranteed to exist, so the last line requires a 
"!" to force-unwrap it.



public func tableView(_ tableView: UITableView, numberOfRowsInSection 
section: Int) -> Int {
let section = self.sections[section]

return section.items.count
}

In this example, we could provide a section number that goes beyond the bounds 
of the self.sections array, without any warning.

My suggestion is perhaps arrays should by default return an optional when given 
an index, and of course they'd support forced-unwrapping too. So you could then 
do this:

let section = self.sections[section]
if section == nil {
return 0
} else {
return section!.items.count
}

Or you could do this:

let section = self.sections[section]!

return section.items.count

Of course this would be less convenient in a lot of cases, but this is the 1 
place where apps seem to encounter a crash, crashing for the same reason that's 
especially avoided across most of the rest of Swift.

My understanding is that we need the current behavior to meet performance 
goals. We've discussed adding a "safe" subscript before, but the discussion 
usually fizzles out when no clear winner for the argument label emerges.

- Dave Sweeris
___
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] switch must be exhaustive, consider adding a default clause

[Josh Parmenter via swift-evolution]

On Apr 10, 2017, at 9:53 AM, Kevin Nattinger 
<sw...@nattinger.net<mailto:sw...@nattinger.net>> wrote:


On Apr 10, 2017, at 9:18 AM, Josh Parmenter via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:

case .none isn’t handled.

It shouldn’t need to be handled in the second switch because it’s impossible. 
Not just developer thinks “impossible” but easily provable by static analysis 
the compiler is doing it anyway—I wouldn’t be surprised if including the case 
resulted in an “unreachable code” warning (in fact, it probably should).

Why? Because of preconditionFailure? That COULD be optimized out as per this 
documentation:

/// * In `-Ounchecked` builds, the optimizer may assume that this function is
///   never called. Failure to satisfy that assumption is a serious
///   programming error.

So I’m not sure if that is the case or not.

This should probably be on the swift-users list though, no?

File a bug, IMO.

Yes - it should probably be looked at by someone who would know if this a bug 
or the expected behavior.

Best,
Josh


Best,
Josh



On Apr 8, 2017, at 11:29 AM, Drew Crawford via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org><mailto:swift-evolution@swift.org>>
 wrote:



Is there a good reason we do not compile this:

import UIKit

func foo(operation: UINavigationControllerOperation) {
   switch(operation) {
   case .push: /* snip */ break
   case .pop: /* snip */ break
   default:
   preconditionFailure("This is a silly operation")
   }
   switch(operation) {
   case .push: /* snip */ break
   case .pop: /* snip */ break
//error: Switch must be exhaustive, consider adding a default clause
   }
}

The switch *is* exhaustive, because the default case is unreachable.  The 
compiler could infer as much from branch analysis.

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


Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com<http://www.vectorform.com/><http://www.vectorform.com/>

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
___
swift-evolution mailing list
swift-evolution@swift.org<mailto: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] switch must be exhaustive, consider adding a default clause

[Josh Parmenter via swift-evolution]

case .none isn’t handled.
This should probably be on the swift-users list though, no?
Best,
Josh



On Apr 8, 2017, at 11:29 AM, Drew Crawford via swift-evolution 
> wrote:



Is there a good reason we do not compile this:

import UIKit

func foo(operation: UINavigationControllerOperation) {
switch(operation) {
case .push: /* snip */ break
case .pop: /* snip */ break
default:
preconditionFailure("This is a silly operation")
}
switch(operation) {
case .push: /* snip */ break
case .pop: /* snip */ break
 //error: Switch must be exhaustive, consider adding a default clause
}
}

The switch *is* exhaustive, because the default case is unreachable.  The 
compiler could infer as much from branch analysis.

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


Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift null safety questions

[Josh Parmenter via swift-evolution]

On Mar 6, 2017, at 7:52 PM, Elijah Thomas Johnson via swift-evolution 
> wrote:

Says: Fix it: Insert !
Should say: Fix it: Use optional binding.

I agree with this in general. I tell people that I’m teaching that unwrapping 
uses ‘!' for a reason. It should scream at you that something is happening that 
probably needs more careful attention.

Best,
Josh


Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD

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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Josh Parmenter via swift-evolution]

Honestly, I think this is one of the rougher parts of the language to see 
problems in. In my opinion, anything that can be done to either warn of retain 
cycles or enforce a better practice in this would be valuable.
Josh

On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution 
> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that looked 
like:

self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping closure, 
and `relatedObjectDidFinish` is a method of `self`. From a memory management 
perspective, this code is equivalent to:

self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish 
})

In the second example, an explicit `self.` is required. It’s my understanding 
that this is to highlight that the closure keeps a strong reference to `self`. 
But, when passing a method, there is no such requirement, which makes it easier 
to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing a 
method as an escaping closure. And whether that would help in the same way that 
the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)

What do you think?

Alex Johnson
ajohn...@walmartlabs.com
ajohnson on Slack
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution



Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD

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

Re: [swift-evolution] Strings in Swift 4

[Josh Parmenter via swift-evolution]

I’ve just done a first read through of this, and in general I feel like this is 
very well thought out, and lessons from Swift 2 and 3 are well incorporated. 
I’ll try to give other feedback later when I have more time, but on an initial 
glance, thanks for this!
Best,
Josh

On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolution 
> wrote:

Hi all,

Below is our take on a design manifesto for Strings in Swift 4 and beyond.

Probably best read in rendered markdown on GitHub:
https://github.com/apple/swift/blob/master/docs/StringManifesto.md

We’re eager to hear everyone’s thoughts.

Regards,
Ben and Dave


# String Processing For Swift 4

* Authors: [Dave Abrahams](https://github.com/dabrahams), [Ben 
Cohen](https://github.com/airspeedswift)

The goal of re-evaluating Strings for Swift 4 has been fairly ill-defined thus
far, with just this short blurb in the
[list of 
goals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html):

**String re-evaluation**: String is one of the most important fundamental
types in the language.  The standard library leads have numerous ideas of how
to improve the programming model for it, without jeopardizing the goals of
providing a unicode-correct-by-default model.  Our goal is to be better at
string processing than Perl!

For Swift 4 and beyond we want to improve three dimensions of text processing:

 1. Ergonomics
 2. Correctness
 3. Performance

This document is meant to both provide a sense of the long-term vision
(including undecided issues and possible approaches), and to define the scope of
work that could be done in the Swift 4 timeframe.

## General Principles

### Ergonomics

It's worth noting that ergonomics and correctness are mutually-reinforcing.  An
API that is easy to use—but incorrectly—cannot be considered an ergonomic
success.  Conversely, an API that's simply hard to use is also hard to use
correctly.  Acheiving optimal performance without compromising ergonomics or
correctness is a greater challenge.

Consistency with the Swift language and idioms is also important for
ergonomics. There are several places both in the standard library and in the
foundation additions to `String` where patterns and practices found elsewhere
could be applied to improve usability and familiarity.

### API Surface Area

Primary data types such as `String` should have APIs that are easily understood
given a signature and a one-line summary.  Today, `String` fails that test.  As
you can see, the Standard Library and Foundation both contribute significantly 
to
its overall complexity.

**Method Arity** | **Standard Library** | **Foundation**
---|:---:|:---:
0: `ƒ()` | 5 | 7
1: `ƒ(:)` | 19 | 48
2: `ƒ(::)` | 13 | 19
3: `ƒ(:::)` | 5 | 11
4: `ƒ()` | 1 | 7
5: `ƒ(:)` | - | 2
6: `ƒ(::)` | - | 1

**API Kind** | **Standard Library** | **Foundation**
---|:---:|:---:
`init` | 41 | 18
`func` | 42 | 55
`subscript` | 9 | 0
`var` | 26 | 14

**Total: 205 APIs**

By contrast, `Int` has 80 APIs, none with more than two parameters.[0] String 
processing is complex enough; users shouldn't have
to press through physical API sprawl just to get started.

Many of the choices detailed below contribute to solving this problem,
including:

 * Restoring `Collection` conformance and dropping the `.characters` view.
 * Providing a more general, composable slicing syntax.
 * Altering `Comparable` so that parameterized
   (e.g. case-insensitive) comparison fits smoothly into the basic syntax.
 * Clearly separating language-dependent operations on text produced
   by and for humans from language-independent
   operations on text produced by and for machine processing.
 * Relocating APIs that fall outside the domain of basic string processing and
   discouraging the proliferation of ad-hoc extensions.


### Batteries Included

While `String` is available to all programs out-of-the-box, crucial APIs for
basic string processing tasks are still inaccessible until `Foundation` is
imported.  While it makes sense that `Foundation` is needed for domain-specific
jobs such as
[linguistic 
tagging](https://developer.apple.com/reference/foundation/nslinguistictagger),
one should not need to import anything to, for example, do case-insensitive
comparison.

### Unicode Compliance and Platform Support

The Unicode standard provides a crucial objective reference point for what
constitutes correct behavior in an extremely complex domain, so
Unicode-correctness is, and will remain, a fundamental design principle behind
Swift's `String`.  That said, the Unicode standard is an evolving document, so
this objective reference-point is not fixed.[1] While
many of the most important operations—e.g. string hashing, equality, and
non-localized comparison—will be stable, the semantics
of others, such as grapheme breaking and localized comparison and case
conversion, are expected to change as platforms are updated, so programs should
be 

Re: [swift-evolution] guard let x = x

[Josh Parmenter via swift-evolution]

On Oct 26, 2016, at 9:37 AM, Chris Lattner via swift-evolution 
> wrote:

To me, this is the most promising direction, but I’d suggest the use of 
“unwrap" as the keyword.  If you compare these two:

a) guard let foobar = foobar else { … }
b) guard unwrap foobar else { … }

I think that b) wins by virtue of eliminating repetition ("foobar = foobar" 
fails DRY principles), but retains clarity by introducing a word into the 
grammar that people already commonly know and use, and which is googlable if 
they don’t.

I find b) to be quite convincing.

Best,

Josh



Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD

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

Re: [swift-evolution] executing a string

[Josh Parmenter via swift-evolution]

I could see a method being implemented that does something bad, but isn’t 
called directly anywhere in code. A code path analysis of a program may miss 
the problematic method (though unlikely?). But if the method signature is 
passed in dynamically as the result of a web call or something, it could then 
be called and cause a problem. However- the malicious code here really is 
already in the binary.

Since app store review is mentioned here, I can’t speak as to how a binary is 
inspected for review, or what tools the app store team has at its disposal. But 
I would be surprised if there isn’t at least some sort of automated step that 
would reveal the code block that might be problematic. And finding another 
instance where calling something by selector would also raise a flag (in fact, 
even Xcode points out the possibility of a leak in these cases). Yes - it MIGHT 
be problematic, but I think there are greater security holes in the iOS / Obj-C 
ecosystem than what is mentioned here. Since it is a compiled language, and 
apps don’t ship with compilers, it seems like the possibility for abuse here is 
not huge. However - many iOS apps can execute JavaScript or create WebViews 
with strings from just about any source - and this is where (it seems to mean) 
a strong sandboxing environment is really needed. But I am curious to know 
(like Félix) if there are examples of this happening.

Best,

Josh

On Jul 14, 2016, at 10:18 PM, Félix Cloutier via swift-evolution 
> wrote:

I've never heard of an app being exploited through selector abuse. Do you have 
any example of that?

Félix

Le 14 juil. 2016 à 08:48:53, Ford Prefect via swift-evolution 
> a écrit :

One of the major security flaws of Obj C is
the ability to convert a string into a selector, which
permits using private methods by constructing selectors
at runtime long after the app store review has been completed.
Does Swift do away with that? I understand it doesn't
use selectors per se but is there an analogous mechanism?

___
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] RFC: didset and willset

[Josh Parmenter via swift-evolution]

I have a general preference for camelCase as well, but I would prefer 
consistency in the language over my own personal preference.

Best,
Josh

> On May 18, 2016, at 1:56 PM, Krystof Vasa via swift-evolution 
>  wrote:
> 
> Not to mention @NSApplicationMain, @NSManaged, ...
> 
> I'd personally keep it camelCase.
> 
>> On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Just some context:
>> 
>> "We have a few conjoined keywords already (typealias, associatedtype, 
>> fallthrough).  In the discussion about these terms, we decided that these 
>> read best when all lowercase, because they are treated as atomic concepts by 
>> programmers"
>> 
>> and
>> 
>> "On it being a conjoined word, we agreed that the language is currently 
>> inconsistent (we have typealias, fallthrough, but also didSet/willSet and 
>> @warn_unused_result) and that we should clean it up.  Conjoined feels like 
>> the right direction to go for this case.  We didn’t discuss it but IMO, 
>> didSet should get lowercased as well."
>> 
>> -- E
>> 
>> 
>>> On May 18, 2016, at 2:50 PM, Sean Heber  wrote:
>>> 
>>> +1 on not getting rid of willSet and didSet for sure!
>>> 
>>> As for naming, it doesn’t bother me much either way, but I think lowercase 
>>> makes sense with the direction everything else is going.
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
 On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution 
  wrote:
 
 Hi Erica,
 
 "didset" and "willset" are outliers in the general rule that when 
 combining multiple words into an identifier, that you should use 
 camelCase. which rule is more important? I'd like to introduce a third 
 rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep 
 it the way it is. or another one: embrace precedent.. "@IBOutlet" is also 
 not all-lowercase, should it be changed too? I'd say no, because in objc 
 it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" 
 and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
 
 => I vote for "didSet" and "willSet".
 
 I think we should be more careful when trying to argue with "consistency". 
 It sounds objective, when in reality it's often very subjective, because 
 Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be 
 consistent. If you are saying that something is inconsistent, you either 
 assert a specific rule of consistency (like "keywords are always 
 lowercase"), or you must argue that there is no general/sane rule under 
 which the individual parts of the system are consistent.
 
 And for all the others who want to abolish didSet and willSet completely:
 NO WAY! they are both useful and I even used them for real code. For 
 example, from code in my bachelors thesis (it's about polygons):
 
 public var points: Array = [] {
 didSet {
 _area = nil
 _centroid = nil
 }
 }
 
 I want to cache the _area and _centroid of a polygon, because I'm going to 
 use it many many times more often than I change points. I would have to 
 rewrite that code to something like
 
 private var _points: Array = []
 public var points {
 get {
 return _points
 }
 set {
 _area = nil
 _centroid = nil
 _points = newValue
 }
 }
 
 That's not better, and it probably breaks the COW-optimization of the 
 underlying array. (And don't tell me that my design is bad because I use 
 "didSet", I really don't think so.)
 
 -Michael
 
> Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
> :
> 
> didSet and willSet remain outliers in the general rule of conjoined 
> lowercase keywords. Is there any support for bringing these outliers into 
> the fold?
> 
> -- E, going through her "ttd notes" this morning
> 
> ___
> 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
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

[Josh Parmenter via swift-evolution]

I would support this - but I don’t feel like I have the experience yet to vet 
the proposal. I agree that the error handling is still something I feel like 
isn’t as smooth as it should be yet.

I’ll try to take a longer look at this today. Thanks for the reminder.

Best,
Josh

On May 9, 2016, at 12:26 PM, Charles Srstka via swift-evolution 
> wrote:

Anyone have any thoughts, opinions, etc. on this? I find it kind of strange 
that I’ve received off-list feedback from within Apple, but so far it’s been 
generally ignored publicly on the list. Surely I’m not the only one who cares 
about the lack of parity between NSError and ErrorProtocol.

Charles

On May 6, 2016, at 10:16 PM, Charles Srstka 
> wrote:

On May 5, 2016, at 2:06 PM, Charles Srstka via swift-evolution 
> wrote:

I formerly posted a less-fleshed-out version of this in the “Reducing bridging 
magic” thread, but I thought this might warrant its own pitch. What do you all 
think?

MOTIVATION:

Over the past couple of years, Swift has made great strides toward seamless 
interoperability with existing Objective-C APIs, and with SE-0005, SE-0033, 
SE-0057, SE-0062, SE-0064, and SE-0070, seems poised to become even better in 
that regard. However, there still exists one major pain point when going back 
and forth between Swift and Objective-C, and that lies in the area of error 
reporting. Passing errors between Objective-C and Swift APIs is currently quite 
awkward, for several reasons:

- The Swift-approved mechanism for reporting errors is a protocol named 
ErrorType (ErrorProtocol in the latest sources). However, Objective-C represent 
errors using a class named NSError. In addition to being a reference type, 
which feels quite unnatural for an error object by Swift’s conventions, NSError 
follows a completely paradigm from what most ErrorProtocol objects use to store 
errors, using a string-based domain and and integer code, along with a userInfo 
dictionary to store information to be presented to the user. While the domain 
and code are available as methods on ErrorProtocol, they are prefixed with 
underscores, and there is no direct equivalent to userInfo.

- Unlike other Objective-C classes like NSString and NSArray which are 
consistently bridged to value types when presenting Objective-C interfaces to 
Swift, the handling of NSError objects is inconsistent. Objective-C APIs which 
return an error by reference using an autoreleasing NSError ** pointer are 
converted to use the Swift try/catch mechanism, presenting the returned error 
as an ErrorProtocol (which is actually an NSError). Similarly, Swift APIs using 
try/catch are presented to Objective-C as autoreleasing NSError ** pointers, 
and the ErrorProtocol-conforming error is converted to an NSError when it is 
called by Objective-C. However, when passing around error objects in any way 
other than these, the errors are not bridged. An Objective-C API that takes an 
NSError, such as NSApp’s -presentError: method, still leaves NSError as the 
type in the interface presented to Swift, as do the many asynchronous APIs in 
Cocoa that return an NSError as one of the arguments to a completion handler. 
Swift APIs that accept ErrorProtocols, on the other hand, are not presented to 
Objective-C at all, necessitating any such APIs also be declared to take 
NSErrors.

- To convert ErrorProtocols to NSErrors, Swift provides a bridging mechanism, 
invoked via “as NSError”, which wraps the error in a private NSError subclass 
class called _SwiftNativeNSError. This subclass can be cast back to the 
original error type, thus returning the original wrapped error. When a Swift 
API that is marked “throws” is called from Objective-C and then throws an 
error, the same bridging mechanism is invoked. However, this bridging is not 
very useful, since Cocoa tends to use NSError’s userInfo dictionary to present 
error information to the user, and ErrorProtocol contains no equivalent to the 
userInfo dictionary. The result of this is that when a Swift API throws an 
error, and this error is passed to Cocoa, the user tends to get a generic error 
message instead of something actually useful.

- The above problem means that a Swift developer must be very careful never to 
use “as NSError”, and to be sure to construct an NSError when throwing an error 
in an API that may be called from Objective-C, rather than simply throwing the 
error directly, or else the error will not be properly presented. If the 
developer makes a mistake here, it will not be known until runtime. I have 
personally wasted quite a bit of time trying to hunt down points in a 
complicated program where an error was accidentally converted to NSError via 
the bridge rather than explicitly.

- The same problem also puts the Swift developer between a rock and a hard 

Re: [swift-evolution] Dropping NS Prefix in Foundation

[Josh Parmenter via swift-evolution]

David has articulated what I couldn't quite put my finger on, and I agree.
This also comes around to something I probably missed elsewhere in the 
discussion- but is the proposal to make NS classes just look like thus don't 
have NS in Swift? Or is it to write Swift versions of those classes that 
duplicate the functionality of those classes in Swift (for instance, giving 
String the full interface of NSString without actually having it call into 
NSString obj-c code?).
I tried glancing through the discussion and couldn't really find an answer to 
this (though I did it quickly, so my apologies if this is an obvious question 
that has already been answered).
Best
Josh

Sent from my iPhone

On May 8, 2016, at 00:41, David Waite via swift-evolution 
> wrote:

It's not a goal to rewrite Foundation from scratch in Swift. All Swift apps 
that are running out there today are in fact using a combination of Swift, 
Objective-C, C, C++, various flavors of assembly, and more. The goal is to 
present the existing API of Foundation in a way that fits in with the language 
today while allowing us to iteratively improve it over time.

Perhaps my concern is a higher level - I don't understand where Foundation is 
envisioned going.

From my perspective, Foundation is highly coupled to Apple platforms and 
Objective-C on one side, and part of the Swift standard library on the other. 
Perhaps long-term Foundation should be split into two new things - a core 
library for cross-platform swift development, and the infrastructure for 
Objective-C interoperability on apple platforms only.

-DW
___
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] Including yes/no in stdlib as aliases for true/false

[Josh Parmenter via swift-evolution]

I agree - please - just don’t. This is easy enough to create on your own if you 
wish, but I think it is easier for new developers to the language not to have 
to ask what differences there are between ‘true’ and ‘yes’ and ‘YES' … etc


On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution 
> wrote:

-1 from me. We should not introduce two equivalent spellings for the same thing.

(Yes, there are sometimes multiple ways to accomplish something, but they are 
not nearly this close.)

Jordan


On May 4, 2016, at 12:04, Erica Sadun via swift-evolution 
> wrote:

I propose adding yes and no to the standard library as aliases for true and 
false Boolean values. When answering the questions posed by Boolean properties 
and methods, "yes" and "no" may provide better fits than "true" and "false".  
"Should this view be hidden?" "Yes!" "Does this collection contain the number 
2?" "No!". Objective-C solved this by adding macro equivalents, admittedly with 
some attendant fuzziness because boolean implementation details allowed non 0/1 
truth values.

Swift on the other hand has very firm ideas about true and false. Adding yes 
and no literal aliases would enhance code readability with little cost. There's 
minimal historic support among languages for yes/no but Swift is an Apple-y 
kind of language and yes/no is an Apple-y kindness to developers.

I performed a gmane search and did not find a previous thread on this subject.

-- E

___
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




Joshua Parmenter | Software Development

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Josh Parmenter via swift-evolution]

yes - that is a wonderful syntax addition in my opinion.
Josh

> On May 2, 2016, at 2:08 PM, Tod Cunningham via swift-evolution 
>  wrote:
> 
> +1 on the shadow variable idea.  What an awesome idea.
> 
> - Tod
> 
> 
> 
> 
> 
> On 5/2/16, 4:41 PM, "Rod Brown"  wrote:
> 
>> Wow, I'm really sad I missed this while I was writing my last response!
>> 
>> I completely agree with this, and that is a much better solution than the 
>> ones previously suggested.
>> 
>> - Rod
>> 
>> 
>>> On 3 May 2016, at 6:16 AM, David Waite  wrote:
>>> 
>>> It is a bad idea to have the compiler change the interpretation of a type 
>>> without some hard and fast rules; the compiler’s interpretation of the 
>>> optionality of your code will result in your code being legal or not.
>>> 
>>> In terms of solutions, I would prefer something similar to a guard 
>>> statement that, rather than exiting, shadows a constant or variable with a 
>>> non-optional equivalent type, e.g.
>>> 
>>> shadow var today = today ?? NSDate()
>>> let timeInterval = today.timeIntervalSinceNow
>>> 
>>> -DW
>>> 
 On May 2, 2016, at 1:27 PM, Tod Cunningham via swift-evolution 
  wrote:
 
 "I wonder if we’re pushing down the road of convenience at the expense of 
 truth. The if/guard let syntax is clear that you’re getting a separate 
 reference or copy, but what you’re suggesting is hiding the reality from 
 the user for what I see as relatively little convenience."
 
 It just might be me trying to avoid using !, and especially avoid implicit 
 unwrapped options.  While there is nothing wrong with the following code 
 it makes me very uncomfortable from a defensive programming point of view:
 
  today = today ?? NSDate()
  let timeInterval = today!.timeIntervalSinceNow
 
 Some developer coming along and changing the code could easily introduce a 
 crash, such as by removing the default value.  In the above example, such 
 a change wouldn’t introduce a compiler warning/error and the bug might not 
 reveal itself until a much later.
 
 Also using if-let or guard also doesn’t seem right, in this case, as it 
 should never fail:
 
 today = today ?? NSDate()   // self.today changed!
 if let today = today {
let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
 } else {
assertFailure()
 }
 
 Same issue with guard:
 
 today = today ?? NSDate()   // self.today changed!
 guard let today = today else {
assertFailure()
return //  that should never happen
 }
 let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
 
 This introduces code that just gets in the way of the code’s meaning for 
 cases that should never happen.  Yuck, there has to be a better way!
 
 - Tod
 
 
 
 From: 
 >
  on behalf of Rod Brown via swift-evolution 
 >
 Reply-To: Rod Brown 
 >
 Date: Sunday, May 1, 2016 at 1:25 AM
 To: David Sweeris >
 Cc: Erica Sadun via swift-evolution 
 >
 Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
 
 
 On 1 May 2016, at 3:00 PM, David Sweeris 
 > wrote:
 
 On Apr 30, 2016, at 5:42 PM, Rod Brown 
 > wrote:
 
 Re-sent for Swift Evolution. Response at end.
 
 On 1 May 2016, at 6:31 AM, David Sweeris 
 > wrote:
 I think your idea makes a lot more sense in respect to ensuring we don't 
 have as much magic.
 
 That said, I still wonder about the implications for thread safety etc. 
 While it isn't a focus of Swift 3, it's something to think about whether 
 this promotes a paradigm that cannot be supported in a threaded 
 environment, specifically accessing properties.
 
 The if-let paradigm is a lot stronger for this set of actions. It gains a 
 separate reference or copy to the internal value, and allows you to action 
 it safely. Should the property change in the meantime, it isn't relevant, 
 because you have you own reference/copy, and then you have the right to 
 re-set the property as required.
 
 This, however, would theoretically add in an invisible ! for you. This 
 leaves you unable to handle the situation should the variable have been 
 changed by another thread between your check and your subsequent action.
 
 

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

[Josh Parmenter via swift-evolution]

I think this is a nice suggestion as well.
Best,
Josh

On Apr 28, 2016, at 1:52 PM, Joe Groff via swift-evolution 
> wrote:


On Apr 28, 2016, at 11:44 AM, Xiaodi Wu via swift-evolution 
> wrote:

We all know and love sizeof(), but given that it's different from its C 
counterpart anyway, shouldn't these conform to Swift naming guidelines? In 
other words, after SE-0006, shouldn't these names be as follows?

```
size(of: T.Type)
size(ofValue: T)
stride(of: T.Type)
stride(ofValue: T)
align(of: T.Type)
align(ofValue: T)
```

There are obvious issues with two different things named `stride`, but IMO 
that's best addressed by renaming one of them; the real problem is that the 
word stride is used in two different ways already. Thoughts?

Seems reasonable to me.

-Joe

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



Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Josh Parmenter via swift-evolution]

On Apr 27, 2016, at 17:23, Howard Lovatt via swift-evolution 
> wrote:

I think that you should *always* have to write `override` when implementing a 
protocol method, you can think of this as override an abstract declaration. In 
particular I think the following should be enforced:

protocol A { func a() }
extension A { override func a() { ... } }
struct AnA: A { override func a() { ... } }

protocol B { func b() }
struct AB: B { override func b() { ... } }


I'm rather new to the list - but I would like to say that I agree with this. I 
think it gives clarity both to code readability, and for learning the language.
Best
Josh

I think this change will work out well since it mimics what happened in Java, 
originally the Java annotation `@Override` was used much like `override` is 
currently used in Swift. However it was problematic and was changed so that you 
always add the annotation, as shown above (in the Swift context). One of the 
big advantages of this change is that the error messages are much better (this 
was very noticeable in Java).

This proposal has come up before on swift-evolution, so it obviously has some 
support.

On Thursday, 28 April 2016, Erica Sadun via swift-evolution 
> wrote:
From the Swift Programming Language: Methods on a subclass that override the 
superclass's implementation are marked with override-overriding a method by 
accident, without override, is detected by the compiler as an error. The 
compiler also detects methods with override that don't actually override any 
method in the superclass.

I would like to extend this cautious approach to protocols, forcing the 
developer to deliberately override an implementation that's inherited from a 
protocol extension. This would prevent accidental overrides and force the user 
to proactively choose to implement a version of a protocol member that already 
exists in the protocol extension.

I envision this as using the same `override` keyword that's used in class based 
inheritance but extend it to protocol inheritance:

protocol A {
func foo()
}

extension A {
func foo() { .. default implementation ... }
}

type B: A {

override required func foo () { ... overrides implementation ... }
}


I'd also like to bring up two related topics, although they probably should at 
some point move to their own thread if they have any legs:

Related topic 1: How should a consumer handle a situation where two unrelated 
protocols both require the same member and offer different default 
implementations. Can they specify which implementation to accept or somehow run 
both?

type B: A, C {
override required func foo() { A.foo(); C.foo() }
}

Related topic 2: How can a consumer "inherit" the behavior of the default 
implementation (like calling super.foo() in classes) and then extend that 
behavior further. This is a bit similar to how the initialization chaining 
works. I'd like to be able to call A.foo() and then add custom follow-on 
behavior rather than entirely replacing the behavior.

type B: A {
override required func foo() { A.foo(); ... my custom behavior ... }
}

cc'ing in Jordan who suggested a new thread on this and Doug, who has already 
expressed some objections so I want him to  have the opportunity to bring that 
discussion here.

- E
___
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