Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Andrew Trick via swift-evolution]

> On May 9, 2016, at 4:07 PM, Matthew Johnson  wrote:
> 
> I’m also interested in your feedback on whether a proposal around indirect is 
> something worth pursuing right now or whether that is something that should 
> wait until after Swift 3.

I’m not prepared to champion this for Swift 3, I think there are enough other 
important proposals on the table, and this is an area that requires careful 
design. If I did have to pick features that we touched on in this thread from 
most to least important I would say:
1. Indirect structs
2. Mutability of reference/class types
3. Automation or annotations for CoW types.
4. Annotations that constrain function side effects.

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

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

[Vladimir.S via swift-evolution]

Yes, I feel like 'within' is much better than 'bounded'.

How about such changes in proposal:

a[bounded: -1 ..< 5]  -->  a[within: -1 ..< 5]  (or a[inside: -1 ..< 5] )

a[optional: 0 ..< 5]  -->  a[checking: 0 ..< 5]
a[optional: 5]-->  a[checking: 5]

?

On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:

I like the idea of the of the bounded subscript, however the optional one I
feel could be used for clumsy code.

.first and .last have value, but once you start stepping several arbitrary
indices in, then that code is likely fragile?


I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names
for ‘bounded’ that attempt to explain what is going on:

let a = [1, 2, 3]

a[within: 0 ..< 5] // [1, 2, 3]
a[inside: 0 ..< 5] // [1, 2, 3]
a[intersecting: 0 ..< 5] // [1, 2, 3]



On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution
> wrote:

As we have discussed throughout this thread, the initial proposal was
modified to include alternative subscript methods instead of modifying
the default operator/subscript behaviour.
The first draft is
here: 
https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md

I've also put this as a gist so that you can leave comments with respect
to the proposal document itself. Any suggestion or help is very welcome.
https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8

Regards,

- Luis

On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa
> wrote:

This proposal seeks to provide a safer ..< (aka half-open range
operator) in order to avoid **Array index out of range** errors in
execution time.

Here is my first draft for this proposal:

https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md

In short, doing that in Swift causes a runtime error:

leta =[1,2,3]
letb =a[0..<5]
print(b)

> Error running code:
> fatal error: Array index out of range

The proposed solution is to slice the array returning all elements
that are below the half-open operator, even though the number of
elements is lesser than the ending of the half-open operator. So the
example above would return [1,2,3].
We can see this very behaviour in other languages, such as Python and
Ruby as shown in the proposal draft.

This would eliminate the need for verifications on the array size
before slicing it -- and consequently runtime errors in cases when
the programmer didn't.

Viewing that it is my very first proposal, any feedback will be helpful.

Thanks!

Luis Henrique Borges
@luishborges


___
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] [Proposal] More lenient subscript methods over Collections

[Vladimir.S via swift-evolution]

Sounds good for me.

How about:

a[bounded: -1 ..< 5]  -->  a[within: -1 ..< 5]  (or a[inside: -1 ..< 5] )

a[optional: 0 ..< 5]  -->  a[checking: 0 ..< 5]
a[optional: 5]-->  a[checking: 5]

?

On 10.05.2016 4:29, Brent Royal-Gordon wrote:

lenient -> keep "lenient:" ? "requested:" ? "optional:"?


`checking:`, to indicate that the index will be checked before it's used?


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

Re: [swift-evolution] Move where clause to end of declaration

[Douglas Gregor via swift-evolution]

> On May 2, 2016, at 12:16 AM, David Hart via swift-evolution 
>  wrote:
> 
> Hello swift-evolution,
> 
> I took the pitch originally from Developer to move the where clause out of 
> the generic parameter list, with improvements brought up by Pyry Jahkola, and 
> wrote a proposal for it. I opened a Pull Request, but if anybody wants to 
> bring some modifications to it before it is merged, please let me know what 
> you think:
> 
> Move where clause to end of declaration
> 
> Proposal: SE- 
> 
> Author(s): David Hart , Developer, Pry Jahkola 
> 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> This proposal suggests moving the where clause to the end of the declaration 
> syntax, but before the body, for readability reasons. It has been discussed 
> at length on the following swift-evolution thread:
> 
> [Pitch] Moving where Clauses Out Of Parameter Lists 
> 
>  
> Motivation
> 
> The where clause in declarations can become quite long. When that happens, it 
> breaks the declaration syntax in two, hurting its readability. There is also 
> no good way of formatting the declaration syntax to make it much better.
> 
>  
> Proposed
>  solution
> 
> The proposal suggests moving the where clause at the end of the declaration, 
> but before the body of concerned declarations. With the proposed change, 
> where clauses do not impede the main declaration and are also more easily 
> formattable. For example, here is the same function declaration before and 
> after the change: 
> 
> func anyCommonElements T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element>(lhs: T, _ rhs: U) -> Bool 
> where
> {
> ...
> }
> 
> func anyCommonElements(lhs: T, _ rhs: U) 
> -> Bool where
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> …
Random minor comment: I find that putting the “where” at the end makes this 
almost unreadable, and would very much have preferred

> func anyCommonElements(lhs: T, _ rhs: U) 
> -> Bool
> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element


- Doug

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

Re: [swift-evolution] NSRange and Range

[Douglas Gregor via swift-evolution]

> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello Swift-Evolution,
> 
> I spent some time coding on Linux with Swift 3 (latest developement snapshot) 
> and corelibs-foundation and I’ve hit one major hurdle: passing and converting 
> NSRange and Range around between the different stdlib and Foundation APIs - 
> specifically in regards to String.
> 
> Is there a plan to simplify those pain points by converting all 
> corelibs-foundation APIs to accept/return Range on String instead of NSRange? 
> In that case, can’t we get rid of NSRange completely?


One idea that had come up before was to bridge NSRange to Range, although 
it wouldn’t completely eliminate NSRange because the two types are not 
representationally identical.

- Doug

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

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

[Patrick Smith via swift-evolution]

* What is your evaluation of the proposal?
These sound great! +1. Subcommands, even nested ones like `swift package init`, 
are more solid and easier to remember.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes, I think establishing a clear system is important.

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

* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
I’ve used `npm`, which has similar subcommands and shortcut methods.

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


> On 10 May 2016, at 8:05 AM, Daniel Dunbar via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0085: Package Manager Command Names" begins now and runs 
> through May 12. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> - Daniel
> Review Manager
> 
> 
> ___
> 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] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

[Patrick Smith via swift-evolution]

I like the idea of the of the bounded subscript, however the optional one I 
feel could be used for clumsy code.

.first and .last have value, but once you start stepping several arbitrary 
indices in, then that code is likely fragile?


I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names for 
‘bounded’ that attempt to explain what is going on:

let a = [1, 2, 3]

a[within: 0 ..< 5] // [1, 2, 3]
a[inside: 0 ..< 5] // [1, 2, 3]
a[intersecting: 0 ..< 5] // [1, 2, 3]


> On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution 
>  wrote:
> 
> As we have discussed throughout this thread, the initial proposal was 
> modified to include alternative subscript methods instead of modifying the 
> default operator/subscript behaviour. 
> The first draft is here: 
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
>  
> 
> 
> I've also put this as a gist so that you can leave comments with respect to 
> the proposal document itself. Any suggestion or help is very welcome.
> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8 
> 
> 
> Regards,
> 
> - Luis
> 
> On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa  > wrote:
> This proposal seeks to provide a safer ..< (aka half-open range operator) in 
> order to avoid **Array index out of range** errors in execution time.
> 
> Here is my first draft for this proposal: 
> https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md
>  
> 
> 
> In short, doing that in Swift causes a runtime error:
> let a = [1,2,3]
> let b = a[0..<5]
> print(b)
> 
> > Error running code: 
> > fatal error: Array index out of range
> 
> The proposed solution is to slice the array returning all elements that are 
> below the half-open operator, even though the number of elements is lesser 
> than the ending of the half-open operator. So the example above would return 
> [1,2,3]. 
> We can see this very behaviour in other languages, such as Python and Ruby as 
> shown in the proposal draft.
> 
> This would eliminate the need for verifications on the array size before 
> slicing it -- and consequently runtime errors in cases when the programmer 
> didn't. 
> 
> Viewing that it is my very first proposal, any feedback will be helpful.
> 
> Thanks!
> 
> Luis Henrique Borges
> @luishborges
> 
> ___
> 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] [Review] SE-0074: Implementation of Binary Search functions

[Nate Cook via swift-evolution]

> On May 9, 2016, at 9:48 PM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> * Operations that depend on sorted-ness and use binary predicates should
>>> not be available on all Collections; they're too easy to misuse,
>>> they're hard to name well, and as Nicola Salmoria has noted, they
>>> would not make any sense at all for a Set.
>>> 
>>> * They should be scoped to a kind of collection that bundles
>>> the predicate with the elements, e.g.
>>> 
>>>  let x = Sorted([3, 4, 1, 5, 2], >)  // stores a sorted copy of the 
>>> array
>>>  let y = Sorted(preSorted: 0..<100, <)  // stores a copy of the range
>>> 
>>> Maybe there should also be protocols for this; CountableRange would
>>> already already conform to the immutable version.  We might want a
>>> mutable form of the protocol for sorted collections with
>>> insertion/removal methods.  This whole area needs more design.
>> 
>> I agree with both of these statements, but not with your conclusion.
>> 
>> There are three classes of collections:
>> 
>> 1) Those which are always sorted, like a SortedSet.
>> 2) Those which may or may not be sorted, like an Array.
>> 3) Those which are never sorted, like a Set.
>> 
>> These APIs are useless on a #3, but #2 is still a valuable use case to 
>> support. In particular, it's quite common to use sorted `Array`s, and these 
>> APIs would help you do that.
>> 
>> What I might consider doing is tying this to `RangeReplaceableCollection`. 
>> That protocol is applied only to types which allow insertion at arbitrary 
>> indices, which is a good, though not perfect, proxy for types which might 
>> allow you to manually maintain a sort order. `Array`, `ArraySlice`, 
>> `ContiguousArray`, and the mutable `String` views would get these methods, 
>> while `Set` and `Dictionary` would not.
> 
> We could also introduce a new OrderedCollection protocol. (This would also be 
> useful in the future for supporting `case` pattern matching on collections. 
> It makes sense to pattern-match arrays and other ordered collections in order 
> by element, but you'd expect very different semantics pattern-matching an 
> unordered Set.)
> 

> -Joe

Yet another alternative would be to drop Set and Dictionary down a level to a 
FiniteSequence protocol in between Sequence and Collection. Basically none of 
the index-based collection APIs (i.e. everything except `count` and `isEmpty`) 
make sense on sets and dictionaries. index(where:) was marginally useful with 
dictionaries, but now that Sequence is getting first(where:), née find(...), 
even that isn't necessary.

Nate

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Xiaodi Wu via swift-evolution]

Got it. In that case, count me in as +1 for most of the proposal but -1 on
AttributedString and its ilk. I agree with you and others that types which
are slated to receive the URL/NSURL treatment shouldn't go through an
interim renaming dance.

On Mon, May 9, 2016 at 20:53 Brent Royal-Gordon 
wrote:

> > Unless I'm mistaken, NSURL is not among the types being renamed in this
> proposal?
>
> It is not, because it's already receiving a value-type equivalent. But
> types like `NSAttributedString`, which the Foundation team eventually
> intends to provide value-type equivalents for, *are* in the proposal. I'm
> merely illustrating the problem by using a type which we've already decided
> will get a value-type equivalent.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

[Joe Groff via swift-evolution]

> On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> * Operations that depend on sorted-ness and use binary predicates should
>> not be available on all Collections; they're too easy to misuse,
>> they're hard to name well, and as Nicola Salmoria has noted, they
>> would not make any sense at all for a Set.
>> 
>> * They should be scoped to a kind of collection that bundles
>> the predicate with the elements, e.g.
>> 
>>   let x = Sorted([3, 4, 1, 5, 2], >)  // stores a sorted copy of the 
>> array
>>   let y = Sorted(preSorted: 0..<100, <)  // stores a copy of the range
>> 
>> Maybe there should also be protocols for this; CountableRange would
>> already already conform to the immutable version.  We might want a
>> mutable form of the protocol for sorted collections with
>> insertion/removal methods.  This whole area needs more design.
> 
> I agree with both of these statements, but not with your conclusion.
> 
> There are three classes of collections:
> 
> 1) Those which are always sorted, like a SortedSet.
> 2) Those which may or may not be sorted, like an Array.
> 3) Those which are never sorted, like a Set.
> 
> These APIs are useless on a #3, but #2 is still a valuable use case to 
> support. In particular, it's quite common to use sorted `Array`s, and these 
> APIs would help you do that.
> 
> What I might consider doing is tying this to `RangeReplaceableCollection`. 
> That protocol is applied only to types which allow insertion at arbitrary 
> indices, which is a good, though not perfect, proxy for types which might 
> allow you to manually maintain a sort order. `Array`, `ArraySlice`, 
> `ContiguousArray`, and the mutable `String` views would get these methods, 
> while `Set` and `Dictionary` would not.

We could also introduce a new OrderedCollection protocol. (This would also be 
useful in the future for supporting `case` pattern matching on collections. It 
makes sense to pattern-match arrays and other ordered collections in order by 
element, but you'd expect very different semantics pattern-matching an 
unordered Set.)

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

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Charles Srstka via swift-evolution]

On May 9, 2016, at 7:38 PM, Rod Brown via swift-evolution 
 wrote:
> 
> I am uncertain about the NSCoding proposition as it is not a generic concept 
> that is platform agnostic. It is a baked in, Objective-C, Apple-only paradigm 
> that seems to me should retain it’s NS prefix.

Plus, NSCoding has a *lot* of legacy cruft associated with it that we would do 
well to jettison with a brand-new coding protocol, IMO.

Charles

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

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

[Nate Cook via swift-evolution]

>> Proposal:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0074-binary-search.md
>>  
>> 
> On May 6, 2016, at 5:16 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> I am posting this review on behalf of Dmitri Gribenko, Max Moiseev, and
> myself.

Thanks for the feedback! This reply is only from me—I haven't had a chance to 
consult with the other authors and they may disagree with me or have better 
arguments on everything below. 

>>  * What is your evaluation of the proposal?
> 
> We think binary searches are fundamental and important, and want to see
> them added.  However, we don't agree with the form of the current
> proposal.  In particular, we think:
> 
> * Operations that depend on sorted-ness and use binary predicates should
>  not be available on all Collections; they're too easy to misuse,
>  they're hard to name well, and as Nicola Salmoria has noted, they
>  would not make any sense at all for a Set.
> 
> * They should be scoped to a kind of collection that bundles
>  the predicate with the elements, e.g.
> 
>let x = Sorted([3, 4, 1, 5, 2], >)  // stores a sorted copy of the 
> array
>let y = Sorted(preSorted: 0..<100, <)  // stores a copy of the range
> 
>  Maybe there should also be protocols for this; CountableRange would
>  already already conform to the immutable version.  We might want a
>  mutable form of the protocol for sorted collections with
>  insertion/removal methods.  This whole area needs more design.

I can certainly see this as an alternate approach. I would still prefer to have 
access to APIs that require but don't enforce sorting as a precondition, since, 
as Brent mentioned, sorted arrays are fairly common. That said, if there's a 
thoughtfully designed collection protocol and a "sorted collection" wrapper 
that doe smart things without duplicating storage, I'd be on board with that as 
well.

> * The polarity of the predicates is wrong: a method with a “where:
>  predicate” should always return you the index of an element that
>  *does* satisfy the predicate.

Wow, yeah, this is totally backwards. So these should really be: 

let a = [10, 20, 30, 30, 30, 40, 60]
a.partitionedIndex(where: { $0 >= 20 }) // 1

let lowerBound30 = a.partitionedIndex(where: { $0 >= 30 })
let upperBound30 = a.partitionedIndex(where: { $0 > 30 })

> * Any code in the proposal should be updated to:
> 
>  - conform to the new
>indexing model; it still shows indices being moved without
>participation of the collection instance.
> 
>  - attach the @noescape attribute to a parameter's type, rather than 
>its name.
> 
> * The existing partition algorithms in the stdlib are indeed hobbled.
>  The more-general partition function is a great idea, but it belongs in
>  a separate proposal.
> 
> * Something like the method the proposal calls `partitionedIndex`
>  *should* be included in the standard library for Swift 3, with the
>  following differences:
> 
>  - it should be called partitionPoint(where:)
> 
>  - the meaning of the predicate result should be inverted so that the
>result of calling the function points to an element actually
>satisfying the predicate
> 
>  This would give people the primitive they need to build higher-level
>  functionality without broadening the interface too far, or committing
>  us to a design that will be hard to use correctly.

This would definitely be a more limited and focused proposal. Thanks again for 
the feedback!

Nate

>>  * Is the problem being addressed significant enough to warrant a
>> change to Swift?  
> 
> Yes.
> 
>> * Does this proposal fit well with the feel and direction of Swift?  
> 
> Not as written, we think.
> 
>> * If you have used other languages or libraries with a similar
>> feature, how do you feel that this proposal compares to those?
> 
> We have used the C++ standard library and Python's `bisect` function.
> This proposal is obviously inspired by much of the work in C++, but we
> think we can do much better for Swift.
> 
>> * How much effort did you put into your review? A glance, a
>> quick reading, or an in-depth study?
> 
> An in-depth study.  
> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> Thanks,
> 
> -- 
> Dave
> 
> ___
> 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] Reducing the bridging magic in dynamic casts

[Joe Groff via swift-evolution]

> On May 9, 2016, at 2:28 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> 
>> Right, you'd need to do NSString(string) as AnyObject to explicitly bridge. 
> 
> Okay great I'm fine with that. :)
> 
>> The @objc-ness of AnyObject is more or less an implementation detail. On 
>> Darwin platforms at least, AnyObject still has the magic ability to dispatch 
>> to all @objc methods, similar to `id` in Objective-C, which vaguely defends 
>> its @objc-ness. (If we're going to rename it, my own preference would be to 
>> drop the Any and just call it `Object`, since we don't put Any in any other 
>> protocol names.) 
> 
> Did I miss something again? I checked SR-0006 and it still has protocols like 
> `Any`, `AnyIterator` or `AnyCollectionProtocol`.

"Any" is a typealias for the protocol type without any protocol requirements, 
which is natively spelled "protocol<>". "AnyIterator" and "AnyCollection" are 
both wrapper types for holding a value that conforms to the Iterator or 
Collection protocol; they aren't protocols themselves.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Brent Royal-Gordon via swift-evolution]

> Unless I'm mistaken, NSURL is not among the types being renamed in this 
> proposal?

It is not, because it's already receiving a value-type equivalent. But types 
like `NSAttributedString`, which the Foundation team eventually intends to 
provide value-type equivalents for, *are* in the proposal. I'm merely 
illustrating the problem by using a type which we've already decided will get a 
value-type equivalent.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

[Brent Royal-Gordon via swift-evolution]

> lenient -> keep "lenient:" ? "requested:" ? "optional:"?

`checking:`, to indicate that the index will be checked before it's used?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

[Brent Royal-Gordon via swift-evolution]

> * Operations that depend on sorted-ness and use binary predicates should
>  not be available on all Collections; they're too easy to misuse,
>  they're hard to name well, and as Nicola Salmoria has noted, they
>  would not make any sense at all for a Set.
> 
> * They should be scoped to a kind of collection that bundles
>  the predicate with the elements, e.g.
> 
>let x = Sorted([3, 4, 1, 5, 2], >)  // stores a sorted copy of the 
> array
>let y = Sorted(preSorted: 0..<100, <)  // stores a copy of the range
> 
>  Maybe there should also be protocols for this; CountableRange would
>  already already conform to the immutable version.  We might want a
>  mutable form of the protocol for sorted collections with
>  insertion/removal methods.  This whole area needs more design.

I agree with both of these statements, but not with your conclusion.

There are three classes of collections:

1) Those which are always sorted, like a SortedSet.
2) Those which may or may not be sorted, like an Array.
3) Those which are never sorted, like a Set.

These APIs are useless on a #3, but #2 is still a valuable use case to support. 
In particular, it's quite common to use sorted `Array`s, and these APIs would 
help you do that.

What I might consider doing is tying this to `RangeReplaceableCollection`. That 
protocol is applied only to types which allow insertion at arbitrary indices, 
which is a good, though not perfect, proxy for types which might allow you to 
manually maintain a sort order. `Array`, `ArraySlice`, `ContiguousArray`, and 
the mutable `String` views would get these methods, while `Set` and 
`Dictionary` would not.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Rod Brown via swift-evolution]

> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
>  
> 
> Reply text
> 
>> What is your evaluation of the proposal?
> +1 to all except renaming classes that are planned in the future to become 
> value types, and the NSCoding issue.
> 
> I agree with Brent that I am unconvinced we should take off NS from those we 
> have identified as future value types. Classes we highly suspect should 
> become value types should retain their NS prefix at this time, as preparation 
> to avoid the mess that would be to come from reverting, deprecating etc. Just 
> because we don’t have enough time to get these value types sorted right away 
> doesn’t mean we should shoot ourselves in the foot by changing things we’ve 
> already identified as high potential for Value Type Transition. If we 
> identify other types later on that should move to value semantics, these 
> strategies would work, but I wonder why deliberately create a headache for 
> ourselves?
> 
> I am uncertain about the NSCoding proposition as it is not a generic concept 
> that is platform agnostic. It is a baked in, Objective-C, Apple-only paradigm 
> that seems to me should retain it’s NS prefix.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> It’s important to get Swift Foundation and Objective-C Foundation heading in 
> the right direction, and to provide for more Swiftification in Foundation in 
> the future, so I think this is significant enough.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Yes and no. I agree with Brent that dropping NS on high-probability value 
> types is not a wise move, and will slow down value type adoption. It seems 
> easier to deprecate the name with NS at a later date if it is determined it 
> must stay a reference type, than it would be trying to go the other way when 
> we decide to move something to value type.
> 
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> N/A
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> Read through the proposal, and have followed the preceding discussions 
> regarding value type adoption and the name transition.
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Charles Srstka via swift-evolution]

I’m afraid I generally have to agree with this criticism. For types like NSURL 
which would make sense to become value types in the future, dropping the prefix 
does seem as if it would put constraints on future growth.

I do think the enum hoisting is great, though, and if it were in a separate 
proposal I’d definitely +1 it.

Charles

> On May 9, 2016, at 6:57 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>  • What is your evaluation of the proposal?
> 
> I support the enum hoisting and case renaming, but not the dropping of the 
> "NS" prefix quite this widely, for several reasons:
> 
> 1. I agree with the critique that "NSCoder" and its ilk should retain their 
> "NS" prefix because they represent something very specific to Foundation, not 
> some general concept of a "coder". ("JSONSerialization", on the other hand, 
> *is* something quite generic.)
> 
> 2. I think the "NS" prefixes may be a valuable indicator of which types are 
> values and which are references. (For this to be the case, we might need to 
> drop some NS prefixes from certain enums.)
> 
> 3. I am wholly unconvinced by the arguments in the "Keep NS on future value 
> types" section.
> 
> Another proposal (I'm behind, so I'm not sure if it's been accepted) suggests 
> that we add a value-typed `URL` to Foundation. Think about what would happen 
> if that proposal were deferred to Swift 4: `NSURL` would be renamed to `URL` 
> in Swift 3, and then Swift 4 would want to use `URL` for something else. At 
> that point, we have several choices, none of them very nice:
> 
> * Rename uses of `URL` back to `NSURL`, only one version after making the 
> opposite change. Note that this doesn't only mean migrating code, but also 
> developers' understanding of the frameworks—people will misread code for a 
> while.
> 
> * Choose a different name for the new value-typed `URL`, like `URLValue` or 
> `URI` or something. The preferred type then gets a suboptimal name.
> 
> * Deprecate the `URL` name, encourage use of `NSURL` instead, and delay the 
> introduction of the new `URL` for a version or two while the deprecation 
> works its magic. Now we've slowed down the evolution of the language.
> 
> Any of these seems like a huge own goal next to the alternative of simply 
> leaving all (or most) NS prefixes in place, at least until we feel the main 
> work of adding value types to Foundation is complete.
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Sure, Foundation needs some cleanup. Just not *this* cleanup.
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> Yes and no. I worry it'll slow the adoption of value types by Foundation, 
> which would not be a good thing.
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> N/A.
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Quick reading, I suppose.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Brent Royal-Gordon via swift-evolution]

>   • What is your evaluation of the proposal?

I support the enum hoisting and case renaming, but not the dropping of the "NS" 
prefix quite this widely, for several reasons:

1. I agree with the critique that "NSCoder" and its ilk should retain their 
"NS" prefix because they represent something very specific to Foundation, not 
some general concept of a "coder". ("JSONSerialization", on the other hand, 
*is* something quite generic.)

2. I think the "NS" prefixes may be a valuable indicator of which types are 
values and which are references. (For this to be the case, we might need to 
drop some NS prefixes from certain enums.)

3. I am wholly unconvinced by the arguments in the "Keep NS on future value 
types" section.

Another proposal (I'm behind, so I'm not sure if it's been accepted) suggests 
that we add a value-typed `URL` to Foundation. Think about what would happen if 
that proposal were deferred to Swift 4: `NSURL` would be renamed to `URL` in 
Swift 3, and then Swift 4 would want to use `URL` for something else. At that 
point, we have several choices, none of them very nice:

* Rename uses of `URL` back to `NSURL`, only one version after making the 
opposite change. Note that this doesn't only mean migrating code, but also 
developers' understanding of the frameworks—people will misread code for a 
while.

* Choose a different name for the new value-typed `URL`, like `URLValue` or 
`URI` or something. The preferred type then gets a suboptimal name.

* Deprecate the `URL` name, encourage use of `NSURL` instead, and delay the 
introduction of the new `URL` for a version or two while the deprecation works 
its magic. Now we've slowed down the evolution of the language.

Any of these seems like a huge own goal next to the alternative of simply 
leaving all (or most) NS prefixes in place, at least until we feel the main 
work of adding value types to Foundation is complete.

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

Sure, Foundation needs some cleanup. Just not *this* cleanup.

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

Yes and no. I worry it'll slow the adoption of value types by Foundation, which 
would not be a good thing.

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

N/A.

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

Quick reading, I suppose.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Modify optional method semantics for swift

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 9, 2016, at 5:53 PM, Rod Brown  wrote:
> 
> Response inline
> 
> 
>> On 10 May 2016, at 8:28 AM, Matthew Johnson  wrote:
>> 
>> 
>>> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution 
>>>  wrote:
>>> 
>>> The problem then becomes how do we model such optimizations in Swift. 
>>> Default methods, while useful for plenty of cases, don't work with this 
>>> system as there is no runtime check to see if the object actually 
>>> implements that method. The optimizations don't just check the existence 
>>> for a default value - they actually lead to different code paths.
>>> 
>>> Can this be done? Absolutely. Either by segregating the protocols as you 
>>> mentioned, or by adding some other way to cue the optimized sizing path. 
>>> That said, it's certainly not as clean as the Objective-C design.
>> 
>> Clean is in the eye of the beholder.  I definitely don’t think the 
>> Objective-C design feels right in Swift.  
>> 
>> There have been times where I implemented delegates where the row height 
>> strategy was decided at initialization time.  In Objective-C I was able to 
>> do this by implementing respondsToSelector.  That feels a bit dirty, but it 
>> works.  In pure Swift there is no way to do that at all.  
>> 
>> Swift allows a delegate protocol design to take a position on whether the 
>> initialization-time decision is supported or is a code smell that should be 
>> disallowed.  The approach of segregated protocols disallows it.  Alternative 
>> mechanisms such as a boolean getter allow for it.
> 
> I agree with this completely. By clean I was referring to the fact it's more 
> concise, not that it's a good fit for the language. I don't think we should 
> adopt this feature in Swift without seriously considering the implications 
> because the nature of Swift's protocols is very different to that of Obj-C. I 
> suspect there are better ways to model this behavior without breaking the 
> philosophical underpinnings of Swift Protocols.
> 
>>> 
>>> In general, I think default implementations fix a lot of the simpler cases 
>>> surrounding optional methods and actually simplify other implementations 
>>> (no runtime checks!). But they don't solve the real value proposition that 
>>> the fully dynamic Objective-C design provided in this feature.
>>> 
>>> Do I support default implementations on protocols as a concept? Definitely. 
>>> But I don't think we should kid ourselves that this solves anything apart 
>>> from the simpler cases.
>> 
>> I agree with this.  I think we should study the more complex cases and 
>> establish guidelines around idiomatic patterns for them in Swift.  This may 
>> even result in proposals for language enhancements to support the idioms we 
>> want to see in Swift.  But I’m glad to see “optional requirements” going 
>> away.
>> 
>> -Matthew
> 
> I don't think they're going away at this time, so much as we are clarifying 
> what is already the case: they are an Obj-C only feature, and aren't 
> supported in Swift standalone. They make sense and will continue to make 
> sense in an Obj-C world, but they're not a foundational element of Swift.

Agree.  I said going away with an indefinite, likely long time frame in mind.  
:)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 9, 2016, at 1:03 PM, Andrew Trick  wrote:
> 
> 
>> On May 9, 2016, at 8:34 AM, Matthew Johnson > > wrote:
>> 
>>> I would prefer to wait until indirect structs and improved CoW support have 
>>> had more discussion.
>> 
>> I've been thinking a lot about Dave's desire to "mandate" that value 
>> semantic types must be value types and allowing us to use reference identity 
>> for equality of reference types.  I would support that if these features 
>> were in place so I think shifting to those topics is a good next step for 
>> this discussion.  
>> 
>> Along those lines, I've been thinking about a proposal to allow the indirect 
>> modifier on any property that has a value type.  It may also be useful to 
>> allow the indirect modifier directly on struct and enum to allow type 
>> authors to indicate that all instances should be indirect.  Do you think it 
>> would it be worthwhile to pursue this proposal now?
>> 
>> Can you elaborate on what you have in mind with regards to improved CoW 
>> support?  Is there any chance of doing something here in Swift 3?
> 
> I don’t have anything specific planned for CoW support in Swift 3, otherwise 
> I would have started a separate thread :)

Sure.  I’m still curious about ideas you have for the future.

I’m also interested in your feedback on whether a proposal around indirect is 
something worth pursuing right now or whether that is something that should 
wait until after Swift 3.


> -Andy

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 8, 2016, at 1:51 AM, Dave Abrahams  wrote:
> 
> 
> on Sat May 07 2016, Andrew Trick  wrote:
> 
>>On May 7, 2016, at 2:04 PM, Dave Abrahams  wrote:
>> 
>>2. Value types are not "pure" values if any part of the aggregate
>>contains a
>>reference whose type does not have value semantics. 
>> 
>>Then Array is not a “pure” value (the buffer contained in an
>>Array is a mutable reference type that on its own, definitely does
>>*not* have value semantics). I don't think this is what you intend, and
>>it indicates that you need to keep working on your definition.
>> 
>> It sounds like you’re changing the definition of value semantics to make it
>> impossible to define PureValue. 
> 
> Not on purpose.
> 
>> Does Array have value semantics then only if T also has value
>> semantics?
> 
> This is a great question; I had to rewrite my response four times.
> 
> In my world, an Array always has value semantics if you respect the
> boundaries of element values as defined by ==.  That means that if T is
> a mutable reference type, you're not looking through references, because
> == is equivalent to ===.
> 
> Therefore, for almost any interesting SomeConstraint that doesn't refine
> ValueSemantics, then
> 
>  Array
> 
> only has value semantics if T has value semantics, since SomeConstraint
> presumably uses aspects of T other than reference identity.  
> 
>> The claim has been made that Array always has value semantics,
>> implying that the array value’s boundary ends at the boundary of it’s
>> element values.
> 
> Yes, an array value ends at the boundary of its elements' values.
> 
>> That fact is what allows the compiler to ignore mutation of the
>> buffer.
> 
> I don't know what you mean here.
> 
>> It's perfectly clear that Array is a PureValue iff T is a PureValue.
>> PureValue is nothing more than transitive value semantics.
> 
> You're almost there.  “Transitive” implies that you are going to look at
> the parts of a type to see if they are also PureValue's.  So which parts
> of the Array struct does one look at, and why?  Just tell me the
> procedure for determining whether a type is a PureValue.

We look at the observable parts.  We do not look at unobservable parts because 
we want flexibility to use things like CoW, shared immutable references, etc in 
our implementation.

Can you share your definition of value semantics?  It may be helpful if we 
start there and refine your definition to exclude impure value types like 
Array.

In the meantime I’ll take another shot:

1. Scalars are pure values.
2. Any aggregate type with value semantics is a pure value iff all observable 
parts of the aggregate are pure values.



> 
>> At any rate, we could add a PureValue magic protocol, and it would have
>> well-defined meaning. I'm not sure that it is worthwhile or even a good way 
>> to
>> approach the problem. But we don't need to argue about the definition.
> 
> I don't want to argue about anything, really.  I just want a definition.
> 
> -- 
> -Dave

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 8, 2016, at 1:19 AM, Dave Abrahams  wrote:
> 
> 
> on Sat May 07 2016, Matthew Johnson  > wrote:
> 
>>On May 7, 2016, at 4:04 PM, Dave Abrahams  wrote:
>> 
>>on Sat May 07 2016, Matthew Johnson  wrote:
>> 
>>I've been thinking about this further and can now state my position 
>> more
>>clearly
>>and concisely.
>> 
>>1. If we're going to have reference types with value semantics the
>>boundary of
>>the value must extend through the reference to the value of the 
>> object.
>>Two
>>instances may have the same logical value so reference equality is not
>>good
>>enough.
>> 
>>My (radical) position has been that we should decree that if you really
>>want this thing to have value semantics, it should be a struct. That
>>is, wrap your reference type in a struct and provide an == that looks at
>>what's in the instance. This radically simplifies the model because we
>>can then assume that value types have value semantics and reference
>>types only have value semantics if you view their identitity as their
>>value.
>> 
>> I agree with this longer term, but it is too soon for that. 
> 
> We don't have much longer to establish the programming model.  It needs
> to happen soon or it will be too late.
> 
>> Rather than suggest wrapping the reference in a struct I would suggest that 
>> most
>> of the time just making it a struct in the first place is the right
>> path. 
> 
> Well of course.  But if you already have a reference type and aren't
> ready to rewrite it, this is how you do it.
> 
>> The problem with this is that it can lead to excessive copying,
>> reference counting, etc if you’re not careful. I argue that mainstream
>> developers should not need to bother with writing a reference type and
>> wrapping it in a struct just to get around this. 
> 
> Sure, maybe our codegen could be smarter about this, but that shouldn't
> hold back the programming model.
> 
>> It would be nice if there were better, less boilerplate-y solutions to
>> this in the future.
>> 
>>2. Value types are not "pure" values if any part of the aggregate
>>contains a
>>reference whose type does not have value semantics. 
>> 
>>Then Array is not a “pure” value (the buffer contained in an
>>Array is a mutable reference type that on its own, definitely does
>>*not* have value semantics). I don't think this is what you intend, and
>>it indicates that you need to keep working on your definition.
>> 
>> I have elaborated elsewhere as to why Array does meet my notion of 
>> “pure”
>> value. I understand that it contains a buffer pointer, etc that does not have
>> value semantics. But that is an implementation detail and is not externally
>> observable. I believe that implementation strategies like this are extremely
>> important. I am only concerned with the externally observable semantics and
>> behavior of the type, not the implementation. 
>> 
>> Just as the internal mutable reference type does not disqualify Array 
>> from
>> having value semantics, it also does not disqualify it from being a “pure
>> value".
> 
> As I've indicated, then, you need a different definition than the one
> above.  And you have to get the definition all together in one place so
> it can be evaluated.
> 
>>Purity must include the entire aggregate. Array has value
>>semantics but it is not a pure value.
>> 
>>In what sense does it have value semantics? Unless we can define
>>equality for Array it's hard to make any claim about its value
>>semantics.
>> 
>> Well it should have value semantics using reference equality of the views
>> because UIView has reference semantics so reference identity is the 
>> appropriate
>> definition of equality. Isn’t that your position as well? 
> 
> Yes.  
> 
>>The primary reasons I can think of for creating reference types with
>>value
>>semantics are avoiding copying everything all the time or using
>>inheritance. (I
>>could also list pre-existing types here but am not as concerned with
>>those)
>> 
>>One could argue that you can avoid copying by writing a struct with a
>>handle and
>>one can simulate inheritance by embedding and forwarding. The problem 
>> is
>>that
>>this involves a lot of boilerplate and makes your code more complex. 
>> 
>>The “forwarding boilerplate problem” is something we need to solve in
>>the language regardless. 
>> 
>> Yes I agree that it needs to be solved regardless. In fact, you might 
>> remember
>> that I invested quite a bit of effort into drafting a proposal on the topic. 
>> I
>> shelved it mostly because I became very busy with client work, but also 
>> partly
>> due to the lukewarm reaction.
>> 
>>The fact that we don't have an answer 

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 8, 2016, at 12:51 AM, Dave Abrahams  wrote:
> 
> 
> on Sat May 07 2016, Matthew Johnson  > wrote:
> 
>>> On May 7, 2016, at 3:03 PM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Sat May 07 2016, Matthew Johnson  wrote:
>>> 
 This depends on the type. For types representing resources, etc it works 
 just
 fine. But for models it does not work unless the model subgraph is entirely
 immutable and instances are unique. 
 I agree that it isn't a good idea to provide a default that will
 certainly be wrong in many cases.
>>> 
>>> Please show an example of a mutable model where such an equality would
>>> be wrong.  
>> 
>> This is somewhat orthogonal to the main points I have been making in
>> this thread.  I have been focused on discussion about reference types
>> that have value semantics and the distinction between value semantics
>> and pure values.  In any case, here you go:
>> 
>> let a: NSMutableArray = [1, 2, 3]
>> let other: NSMutableArray = [1, 2, 3]
>> let same = a === other // false
>> let equal = a == other // true
> 
> That's not proof that an == for NSMutableArray that matches the behavior
> of === would be wrong, just that it would be different from what we
> currently have.  
> 
>> Reference equality does not match the behavior of many existing
>> mutable model types.  You seem to be making a case that in Swift it
>> should.  
> 
> Yes.
> 
>> But that is a separate discussion from the one I am trying to engage
>> in because mutable reference types *do not* have value semantics.
> 
> Then maybe I should disengage here?
> 
   Okay then, what algorithms can you write that operate on PureValue 
 that
   don't work equally well on Array?
>>> 
>>> You haven't answered this question.  How would you use this protocol?
>> 
>> I answered elsewhere but I’ll repeat that one use that immediately
>> comes to mind is to constrain values received in the initializer of a
>> (view) controller to ensure that the observable state will not change
>> over time.  
> 
> My claim is that substituting the constraint of “it has value
> semantics,” while presumably looser than the PureValue constraint, would
> not compromise the correctness of your view controller, so not only is
> the meaning of PureValue hard to define, but it doesn't buy you
> anything.  If you want to refute that, just show me the code.
> 
>> This is not an algorithmic use but is still perfectly valid IMO.
> 
> If the properties of PureValue matter to your view controller, there's
> an algorithm somewhere that depends on those properties for its
> correctness.

In many cases it may just be view configuration that depends on those 
properties.  I suppose you can call view configuration code an algorithm but I 
think that would fall outside of common usage.

> 
>> If I read Andrew’s post correctly it sounds like it may also be of use
>> to the optimizer in some cases.
> 
> FWIW, I'm only interested in how you use this protocol in the
> programming model, and I'm not even sure Andrew is talking about the
> same constraint that you are.

I am also primarily interested in the programming model.  That said, as far as 
I can tell everything Andrew has said is talking about the exact same thing I 
am.  Andrew, if I have said anything that doesn’t align with the constraint 
you’re talking about please let me know!

> 
> 
> -- 
> -Dave

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 8, 2016, at 1:02 AM, Dave Abrahams  wrote:
> 
> 
> on Sat May 07 2016, Matthew Johnson  > wrote:
> 
>>> 
>>> You haven't answered this question.  How would you use this protocol?
>> 
>> I think the best example was given by Andy when discussing pure
>> functions.  Maybe I want to write a generic function and ensure it is
>> pure.  I can only do this if I know that any arguments received that
>> compare equal will always present the same observable state.  
> 
> And that it doesn't touch any globals.
> 
>> For example, maybe I wish to memoize the result.
>> 
>> I cannot write such a function for all T, and I also cannot write such
>> a function for all T that have value semantics if we adopt the
>> “references are values” view of the world.  
> 
> Oh, you absolutely can, because if the function applies to all T that
> have value semantics, it only has a few operations to work with:
> initialization, assignment, and equality.  Assignment is the only
> mutating one of these.

I was implicitly assuming additional constraints exposing other behavior.  I 
should have stated that explicitly.

> 
>> I need an additional constraint that rejects things like
>> Array.  (T would obviously also be constrained by a protocol
>> that exposes the properties or methods my function requires to compute
>> its result)
> 
> Did you just start referring to T as the element type of the array
> instead of the function's parameter type?  I think you're
> unintentionally pulling a fast one, reasoning-wise.  It might help to
> write down some actual code.

I was intending to refer to T as the element type of the array all along.  The 
signature I was thinking of would look something like:

pure foo(bar: [T]) -> SomeReturnType

I should have written this down to be clear about it.

> 
>> In general, it would be used where you need to ensure that the result
>> of any operation observing the state of any part of the aggregate
>> value will always return the same value at any point in the future.
>> If I observe a[0].foo now I know with certainty the result of
>> observing a[0].foo at any point in the future.  
> 
> Sure, but what you need then is a constraint on a's Element type that it
> has value semantics, not some kind of new PureValue concept to use as a
> constraint on the array itself.  

That works if you follow all observable paths until you get to scalars.  For 
example maybe A’s element is Array and `foo ` is implemented in 
an extension off Array where Element == UIVIew (after we get same type 
constraints).  Once we have conditional conformance that extension could 
conform to a protocol that makes `foo` visible and it would still have value 
semantics but it would not be a pure value.

> 
>> This aspect of preservation of observed values across time is
>> essential to the distinction between Array (see below)
>> and Array.  It doesn’t matter when I observe the frames of the
>> elements of Array, I will always get the same rects back.
>> With Array that is obviously not the case as the frame of the
>> view could be mutated by anyone with a reference to the views at any
>> time in between my observations of the frame values.
>> 
>> struct LayoutValue {
>>  frame: CGRect
>> }
>> 
>>> 
   let t = MyClass()
   foo.acceptWrapped(Wrap(t))
   t.mutate()
 
   In this example, foo had better not depend on the wrapped 
 instance
   not
   getting
   mutated.
 
   foo has no way to get at the wrapped instance, so it can't 
 depend on
   anything about it.
 
   Ok, but this is a toy example. What is the purpose of Wrap? Maybe
   foo
   passes the
   wrapped instance back to code that *does* have visibility to the
   instance. My
   point was that shared mutable state is still possible here. 
 
   And my point is that Wrap encapsulates a T (almost—I should 
 have
   let
   it construct the T in its init rather than accepting a T 
 parameter)
   and
   the fact that it's *possible* to code something with the 
 structure
   of
   Wrap so that it has shared mutable state is irrelevant.
 
   The point I am trying to make is that the semantic properties of
   Wrap depend
   on the semantic properties of T (whether or not non-local 
 mutation
   may be
   observed in this case). 
 
   No they do not; Wrap was specifically designed *not* to depend on 
 the
   semantic properties of T. This was in answer to what you said:
 
   A struct wrapping a mutable reference type certainly doesn’t
   “feel” value semantic to me and certainly doesn’t have the
 

Re: [swift-evolution] Modify optional method semantics for swift

[Rod Brown via swift-evolution]

Response inline


> On 10 May 2016, at 8:28 AM, Matthew Johnson  wrote:
> 
> 
>> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution 
>>  wrote:
>> 
>> The problem then becomes how do we model such optimizations in Swift. 
>> Default methods, while useful for plenty of cases, don't work with this 
>> system as there is no runtime check to see if the object actually implements 
>> that method. The optimizations don't just check the existence for a default 
>> value - they actually lead to different code paths.
>> 
>> Can this be done? Absolutely. Either by segregating the protocols as you 
>> mentioned, or by adding some other way to cue the optimized sizing path. 
>> That said, it's certainly not as clean as the Objective-C design.
> 
> Clean is in the eye of the beholder.  I definitely don’t think the 
> Objective-C design feels right in Swift.  
> 
> There have been times where I implemented delegates where the row height 
> strategy was decided at initialization time.  In Objective-C I was able to do 
> this by implementing respondsToSelector.  That feels a bit dirty, but it 
> works.  In pure Swift there is no way to do that at all.  
> 
> Swift allows a delegate protocol design to take a position on whether the 
> initialization-time decision is supported or is a code smell that should be 
> disallowed.  The approach of segregated protocols disallows it.  Alternative 
> mechanisms such as a boolean getter allow for it.

I agree with this completely. By clean I was referring to the fact it's more 
concise, not that it's a good fit for the language. I don't think we should 
adopt this feature in Swift without seriously considering the implications 
because the nature of Swift's protocols is very different to that of Obj-C. I 
suspect there are better ways to model this behavior without breaking the 
philosophical underpinnings of Swift Protocols.

>> 
>> In general, I think default implementations fix a lot of the simpler cases 
>> surrounding optional methods and actually simplify other implementations (no 
>> runtime checks!). But they don't solve the real value proposition that the 
>> fully dynamic Objective-C design provided in this feature.
>> 
>> Do I support default implementations on protocols as a concept? Definitely. 
>> But I don't think we should kid ourselves that this solves anything apart 
>> from the simpler cases.
> 
> I agree with this.  I think we should study the more complex cases and 
> establish guidelines around idiomatic patterns for them in Swift.  This may 
> even result in proposals for language enhancements to support the idioms we 
> want to see in Swift.  But I’m glad to see “optional requirements” going away.
> 
> -Matthew

I don't think they're going away at this time, so much as we are clarifying 
what is already the case: they are an Obj-C only feature, and aren't supported 
in Swift standalone. They make sense and will continue to make sense in an 
Obj-C world, but they're not a foundational element of Swift.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[David Hart via swift-evolution]

> What is your evaluation of the proposal?
+1 I already gave my opinion in the original discussion but I’ll summarise it 
here. I understand the fears that this proposal may inhibit us in the future 
from making the modifications that Foundation needs to make it feel more 
Swifty. But I think that those fears are maybe exaggerated and that this 
proposal is the first step in the right direction.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
This could mean the difference between a good and a great adoption of 
corelibs-foundation, so I think it definitely is significant enough.

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

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

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

I read the proposal in detail and followed the heated debate around the pitch :)

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

Re: [swift-evolution] Modify optional method semantics for swift

[Matthew Johnson via swift-evolution]

> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution 
>  wrote:
> 
> This issue I see here, and one that people seem to often forget in 
> discussions on Swift a Evolution, is that optional methods aren't just used 
> to change a default value. Their existence often actually changes behavior 
> completely.
> 
> Take for example UITableViewDelegate and its method 
> "tableView:heightForRowAtIndexPath:".
> 
> If you implement this method, every cell can have a variable height, and the 
> table cannot optimize for it, so the math, storage and management of the data 
> is specific to every row. This method will be called for every cell in the 
> table view at load, because the table must calculate that size to compute the 
> content size.
> 
> If you do not implement this method, the cell sizing is simple. Table view 
> doesn't have to call this method again and again, but not only that: it can 
> actually optimise the layout with the knowledge that there is no variable 
> sizing. That makes the mathematics of content size so much easier to compute, 
> and results in a far better performing table view, down to even working at 
> 60fps on an original iPhone.
> 
> UITableView has optimized the variable sizing problems recently with 
> estimated values that allow the table to "estimate" the sizing, and then 
> adjust appropriately its details as the cells load. This also how self-sizing 
> cells work. That said, it's an avoidance to deal with the limitations that 
> the method creates: if it exists on the delegate, you're opting into a much 
> slower and less efficient sizing path.
> 
> The problem then becomes how do we model such optimizations in Swift. Default 
> methods, while useful for plenty of cases, don't work with this system as 
> there is no runtime check to see if the object actually implements that 
> method. The optimizations don't just check the existence for a default value 
> - they actually lead to different code paths.
> 
> Can this be done? Absolutely. Either by segregating the protocols as you 
> mentioned, or by adding some other way to cue the optimized sizing path. That 
> said, it's certainly not as clean as the Objective-C design.

Clean is in the eye of the beholder.  I definitely don’t think the Objective-C 
design feels right in Swift.  

There have been times where I implemented delegates where the row height 
strategy was decided at initialization time.  In Objective-C I was able to do 
this by implementing respondsToSelector.  That feels a bit dirty, but it works. 
 In pure Swift there is no way to do that at all.  

Swift allows a delegate protocol design to take a position on whether the 
initialization-time decision is supported or is a code smell that should be 
disallowed.  The approach of segregated protocols disallows it.  Alternative 
mechanisms such as a boolean getter allow for it.

> 
> In general, I think default implementations fix a lot of the simpler cases 
> surrounding optional methods and actually simplify other implementations (no 
> runtime checks!). But they don't solve the real value proposition that the 
> fully dynamic Objective-C design provided in this feature.
> 
> Do I support default implementations on protocols as a concept? Definitely. 
> But I don't think we should kid ourselves that this solves anything apart 
> from the simpler cases.

I agree with this.  I think we should study the more complex cases and 
establish guidelines around idiomatic patterns for them in Swift.  This may 
even result in proposals for language enhancements to support the idioms we 
want to see in Swift.  But I’m glad to see “optional requirements” going away.

-Matthew

> 
> - Rod
> 
> On 10 May 2016, at 2:15 AM, Carlos Rodríguez Domínguez via swift-evolution 
> > wrote: 
> 
>> Rationale:
>> 
>> As a everybody knows, “optional” keyword is present in swift solely to 
>> maintain compatibility with objective-c protocols. Optional methods in 
>> protocols are neither a swift capability, nor a wanted one. In fact, 
>> proposal [0070] intends to begin the transition to an optionals-free 
>> language. In fact, optionals, as presented by objective-c, are a manner to 
>> avoid interface segregation.
>> 
>> Nonetheless, in many occasions, optionals are used to model customized 
>> behavior vs default one. For instance, if you take a look at the 
>> documentation of UITableViewDataSource or delegate, you’ll see that optional 
>> methods are not required, since the framework provides a default behavior 
>> that can be customized by implementing the corresponding optional methods.
>> 
>> Consequently, is most cases, optional methods in objective-c are a means to 
>> replace the semantics of default protocol method implementations, as 
>> supported through extensions in swift.
>> 
>> Therefore, my proposal is to modify the semantics of “optional” keyword in 
>> swift to mean: “you must 

[swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0086 "Drop NS Prefix in Swift Foundation" begins now and runs 
through May 16, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
Reply text

Other replies
 
What
 goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

-Doug Gregor

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

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

[Matthew Johnson via swift-evolution]

> On May 9, 2016, at 12:26 PM, Tony Parker  wrote:
> 
> Hi Matthew (and others),
> 
>> On May 9, 2016, at 9:03 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution 
>>> > wrote:
>>> 
>>> This is exactly the way I see it, too. Many people are coming to Swift
>>> and immediately decrying the language because it doesn't have built-in
>>> support for regex, date parsing, collections beyond the built-in 3,
>>> etc., when it in fact has a rich tapestry of things from Foundation.
>>> 
>>> While I agree with many of the points made in the thread, I think we're
>>> missing the forest for the trees. Foundation is the best at many of the
>>> things it does on any platform. This is in spite of many of the points
>>> made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
>>> It *does* have crufty edges.
>>> 
>>> Foundation not having a super-Swifty API is a solvable problem over
>>> time, of which this is a first step down that road. Revamping the
>>> Foundation API in the Swift 3 timeframe is not a solvable problem.
>> 
>> I agree with everything you say here.  My only concern is trying to ensure 
>> we don't take steps today that will make it difficult to implement the best 
>> design down the road.  
> 
> It’s true that Foundation is the foundation of the Objective-C stack. 
> However, while some see this as a weakness, I see it as a great opportunity. 
> The role of this library puts it in a unique spot as a leverage point: low 
> enough level to be used in nearly all applications on all platforms, but high 
> enough level to establish API and patterns that you see across the SDK.
> 
> The idea of leaving existing API behind somehow by keeping the prefix means 
> that the leverage would be gone. With all existing API in terms of those 
> existing types, any new types are effectively unused in all API above 
> Foundation. We would need to introduce conversion methods to move between the 
> two types (if that is even possible).
> 
> If, instead, we evolve the existing API to be better for Swift, then we 
> benefit the entire stack without having a boil-the-ocean type of adoption 
> problem. Therefore, we have already made the decision that we are not going 
> to invent an entirely new set of a fundamental types but to instead 
> iteratively improve the API of the ones we have.

I understand where you’re coming from and appreciate the reasons for the 
decision.  As a developer working on Apple platforms I will receive immediate 
benefit from this direction in the near term.

At the same time I do think it is a path that could lead to a less cohesive 
community.  We may see alternative, Swift-native libraries emerge especially 
from those using Swift on non-Apple platforms (server side, etc).  I hope the 
“Swiftification of Foundation” is able to move quickly enough and feel 
idiomatic enough to prevent that from happening.  I’m sure you’ve given this 
plenty of thought already internally.

-Matthew

> 
> - Tony
> 
>> 
>>> 
>>> Cheers
>>>  Zach Waldowski
>>>  z...@waldowski.me 
>>> 
 On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:
 If I am coming to Swift as a new user (possibly as a first language,
 even) without any prior Objective-C experience and very little knowledge
 of the long history of Foundation, the NS prefix, etc, this is going to
 feel worse than a little out of place - it will feel downright wrong,
 broken, and confusing to see these weird NS prefixes on some seemingly
 “standard” classes and not on others.
 
 I’m +1 for removing the NS and evolving forward from there - let’s not
 create a confusing tangle of old and new that is navigable only by those
 with knowledge of the esoteric.
 
 l8r
 Sean
 
 
> On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution 
> > wrote:
> 
> I have mixed feelings about this; while I agree that prefixing names 
> isn’t a good fit for Swift, at the same time that’s kind of the appeal of 
> it. Assuming that Foundation will eventually be replaced by a more 
> Swift-like alternative, or will be incrementally reworked, I think it 
> makes sense for it to feel a little weird to use as it is right now.
> 
> The NS prefix makes it clear that this is something different, something 
> not originally designed with Swift in mind, and in a way that’s a good 
> thing. I know in my own case it makes me instinctively shy away from it, 
> and actually encourages me to wrap NS constructs in something more 
> Swift-like for convenience.
> 
>> On 6 May 2016, at 21:52, Tony Parker via 

Re: [swift-evolution] Modify optional method semantics for swift

[Rod Brown via swift-evolution]

This issue I see here, and one that people seem to often forget in discussions 
on Swift a Evolution, is that optional methods aren't just used to change a 
default value. Their existence often actually changes behavior completely.

Take for example UITableViewDelegate and its method 
"tableView:heightForRowAtIndexPath:".

If you implement this method, every cell can have a variable height, and the 
table cannot optimize for it, so the math, storage and management of the data 
is specific to every row. This method will be called for every cell in the 
table view at load, because the table must calculate that size to compute the 
content size.

If you do not implement this method, the cell sizing is simple. Table view 
doesn't have to call this method again and again, but not only that: it can 
actually optimise the layout with the knowledge that there is no variable 
sizing. That makes the mathematics of content size so much easier to compute, 
and results in a far better performing table view, down to even working at 
60fps on an original iPhone.

UITableView has optimized the variable sizing problems recently with estimated 
values that allow the table to "estimate" the sizing, and then adjust 
appropriately its details as the cells load. This also how self-sizing cells 
work. That said, it's an avoidance to deal with the limitations that the method 
creates: if it exists on the delegate, you're opting into a much slower and 
less efficient sizing path.

The problem then becomes how do we model such optimizations in Swift. Default 
methods, while useful for plenty of cases, don't work with this system as there 
is no runtime check to see if the object actually implements that method. The 
optimizations don't just check the existence for a default value - they 
actually lead to different code paths.

Can this be done? Absolutely. Either by segregating the protocols as you 
mentioned, or by adding some other way to cue the optimized sizing path. That 
said, it's certainly not as clean as the Objective-C design.

In general, I think default implementations fix a lot of the simpler cases 
surrounding optional methods and actually simplify other implementations (no 
runtime checks!). But they don't solve the real value proposition that the 
fully dynamic Objective-C design provided in this feature.

Do I support default implementations on protocols as a concept? Definitely. But 
I don't think we should kid ourselves that this solves anything apart from the 
simpler cases.

- Rod

> On 10 May 2016, at 2:15 AM, Carlos Rodríguez Domínguez via swift-evolution 
>  wrote: 
> 
> Rationale:
> 
> As a everybody knows, “optional” keyword is present in swift solely to 
> maintain compatibility with objective-c protocols. Optional methods in 
> protocols are neither a swift capability, nor a wanted one. In fact, proposal 
> [0070] intends to begin the transition to an optionals-free language. In 
> fact, optionals, as presented by objective-c, are a manner to avoid interface 
> segregation.
> 
> Nonetheless, in many occasions, optionals are used to model customized 
> behavior vs default one. For instance, if you take a look at the 
> documentation of UITableViewDataSource or delegate, you’ll see that optional 
> methods are not required, since the framework provides a default behavior 
> that can be customized by implementing the corresponding optional methods.
> 
> Consequently, is most cases, optional methods in objective-c are a means to 
> replace the semantics of default protocol method implementations, as 
> supported through extensions in swift.
> 
> Therefore, my proposal is to modify the semantics of “optional” keyword in 
> swift to mean: “you must provide a default implementation of this method 
> through an extension”. This is different from objective-c semantics, which 
> mean “the implementation of this method may not be provided”.
> 
> Detailed design:
> 
> In this proposal, protocols could be defined like this:
> 
> protocol Datasource {
>   associatedtype Element
> 
>   var count:Int {get}
>   func elementAt(index:Int) -> Element
>   optional func color(elementIndex:Int) -> UIColor
> }
> 
> However, this definition enforces the developer to create an extension a 
> provide a default implementation of the optional method:
> 
> extension Datasource {
>   func color(elementIndex:Int) -> UIColor {
>   return UIColor.blackColor()
>   }
> }
> 
> In this way, what we are achieving is that we are avoiding objective-c 
> optional semantics (which is a way to avoid interface segregation), but we 
> are making explicit that a method in a protocol requires a default 
> implementation, thus not requiring the developer to re-implement the method 
> in any entity adopting the protocol (as it currently happens when we provide 
> a default method implementation). Moreover, we are making explicit that a 
> certain protocol method has a default 

[swift-evolution] [Review] SE-0085: Package Manager Command Names

[Daniel Dunbar via swift-evolution]

Hello Swift community,

The review of "SE-0085: Package Manager Command Names" begins now and runs 
through May 12. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

 - Daniel
Review Manager


___
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] UnsafeBytePointer API for In-Memory Layout

[Geordie J via swift-evolution]

> Am 09.05.2016 um 23:04 schrieb Andrew Trick :
> 
> 
>> On May 9, 2016, at 12:38 PM, Geordie Jay > > wrote:
>> 
>> I read this proposal and I'm a bit unsure what its purpose would be:
>> 
>> Basically you want to prevent UnsafePointer(UnsafePointer) 
>> conversions and/or vice-versa? And you'd achieve this by replacing 
>> UnsafePointer with UnsafeBytePointer that has no bound pointer type?
> 
> I want to prevent UnsafePointer(UnsafePointer) *except* when the 
> destination is UnsafePointer.
> 
> UnsafePointer(UnsafePointer) is fine.
> 
> UnsafeBytePointer provides two thing:
> - A means to prevent the conversion above
> - An API for legal type punning, which does not exist today

So you mean to enable UnsafePointer aka. 
UnsafeBytePointer(UnsafePointer), but disable other type-to-type pointer 
recasts? I guess that’s a worthy goal at some level, but is there anything 
stopping someone just saying 
UnsafePointer(UnsafeBytePointer(myPointerToMemoryContainingTypeT), toPointee: 
U.type)?

It still just seems like we can do the same thing spelled differently. I don’t 
see how changing how that happens could benefit us or the compiler, but maybe 
this is one we should just take your word on.

Assuming the likely case that this is just beyond my understanding, I do wonder 
why we’d need to change the API. I guess there are a lot of assumptions made 
about both UnsafePointer and UnsafePointer that don’t necessarily 
apply to both to an equal degree?

> 
>> In one sense the change seems fine to me, but as someone who uses a lot of C 
>> APIs and a lot of CoreAudio/CoreMIDI in Swift already I can't really see 
>> what benefit it'd bring. Presumably we'd still want an option of converting 
>> UnsafeBytePointer to UnsafePointer for things like C 
>> function pointer callback "context"/"userInfo" uses, so it's not like we'd 
>> be preventing programmer error in that way.
> 
> It’s possible to cast UnsafeBytePointer to UnsafePointer. I 
> want the programmer to make their intent explicit  by writing a cast and 
> spelling SomeActualType at the point of the cast. In the proposal, that’s 
> done using a labeled initializer.

How is this different from what we do now, namely 
UnsafePointer(myUnsafePointer) <— I’m also spelling out 
SomeActualType there. I think I’m still misunderstanding something critical 
here.

From your email that just came in:

> if converting UMP types leads to undefined behavior, then it should be 
> prohibited in the API, unless the programming explicitly requests the 
> conversion


This is the point I’d really like to try and understand: can you clarify how 
the new API is any more or less explicit than the old one?

> 
>> Call me conservative but to me the current system seems to work as well as 
>> it can. If anything it's already enough boilerplate going through hoops 
>> converting an UnsafeMutablePointer into a [Float] even when I know and 
>> the C API knows perfectly well what it actually contains... Would happily be 
>> convinced otherwise about this proposal though, I'm pretty new at all this.
> 
> I think you are asking for implicit conversions when calling C APIs. That’s 
> good feedback. When implementing this proposal I tried to allow implicit 
> conversions in reasonable cases, but leaned toward being conservative. I 
> would rather see more explicit casts now and eliminate them if people find it 
> awkward.

Maybe, but I’m not sure how that’d look under this proposal. I mean Strings and 
literals currently being accepted as UnsafePointer is a nice touch, and 
last I checked I can use [T, T, T, ...] array literals in place of 
UnsafePointer, I certainly wouldn’t want to go below that level of 
conservatism here.

> 
> I'm looking for some consensus on core aspects of the proposal, then we can 
> take into consideration precisely which implicit conversions should be 
> supported.
> 
> -Andy
> 
>> Geordie
>> Andrew Trick via swift-evolution > > schrieb am Mo., 9. Mai 2016 um 20:15:
>> Hello Swift evolution,
>> 
>> I sent this to swift-dev last week. Sorry to post on two lists!
>> 
>> Swift does a great job of protecting against undefined behavior--as long as 
>> you avoid "unsafe" APIs, that is. However, unsafe APIs are important for 
>> giving developers control over implementation details and performance. 
>> Naturally, the contract between unsafe APIs and the optimizer is crucial. 
>> When a developer uses an unsafe API, the rules governing safe, well-defined 
>> behavior must be clear. On the opposite end, the optimizer must know which 
>> assumptions it can make based on those rules. Simply saying that anything 
>> goes because "unsafe" is in the name is not helpful to this effort.
>> 
>> For a long time, I've wanted these rules nailed down. We have more users 
>> taking advantage of advanced features, and more optimizations that take 
>> advantage of 

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

[Adrian Zubarev via swift-evolution]

> Right, you'd need to do NSString(string) as AnyObject to explicitly bridge.  

Okay great I'm fine with that. :)  

> The @objc-ness of AnyObject is more or less an implementation detail. On 
> Darwin platforms at least, AnyObject still has the magic ability to dispatch 
> to all @objc methods, similar to `id` in Objective-C, which vaguely defends 
> its @objc-ness. (If we're going to rename it, my own preference would be to 
> drop the Any and just call it `Object`, since we don't put Any in any other 
> protocol names.)  

Did I miss something again? I checked SR-0006 and it still has protocols like 
`Any`, `AnyIterator` or `AnyCollectionProtocol`.  
--  
Adrian Zubarev  

Am 9. Mai 2016 um 21:38:22, Joe Groff 
(jgr...@apple.com(mailto:jgr...@apple.com)) schrieb:

>  
>  
> > On May 6, 2016, at 12:04 AM, Adrian Zubarev via swift-evolution 
> >  wrote:
> >  
> > Definitely a welcome change from me (+1). But this proposal makes me 
> > curious about the impact on the `AnyObject` protocol?
> >  
> > let string = "foo"
> > let nsString = string as AnyObject
> > nsString.dynamicType // _NSCFConstantString.Type
> > NSString().dynamicType // __NSCFConstantString.Type // there are two 
> > different types?
> >  
> > This sample won’t bridge anymore if SE-0083 will be accepted.
>  
> Right, you'd need to do NSString(string) as AnyObject to explicitly bridge.
>  
> > Can we also drop the @objc from `AnyObject` protocol and leave it as an 
> > implicit protocol for classes? (Personally I’d rename `AnyObject` to 
> > `AnyReference` if Swift will introduce other reference types.)
>  
> The @objc-ness of AnyObject is more or less an implementation detail. On 
> Darwin platforms at least, AnyObject still has the magic ability to dispatch 
> to all @objc methods, similar to `id` in Objective-C, which vaguely defends 
> its @objc-ness. (If we're going to rename it, my own preference would be to 
> drop the Any and just call it `Object`, since we don't put Any in any other 
> protocol names.)
>  
> > This change might allow the replacement of the `class` keyword from 
> > protocols with the implicit `AnyObject` protocol, which can be discussed in 
> > this thread: Should we rename "class" when referring to protocol 
> > conformance?
> >  
> > One more thing I’d like to ask: is there any possibility of adding a new 
> > `bridge` keyword, which would allow explicit bridging to a different 
> > language type (ObjC, etc. if there are any more languages we can bridge to 
> > [C or maybe one day C++])?
> >  
> > T `bridge` U
> > T? `bridge` U?
>  
> One could write `bridge` as a method in most cases; it doesn't need to be a 
> keyword with special syntax, since you could write `T.bridge(U.self)` (or, if 
> we accept https://github.com/apple/swift-evolution/pull/299, `T.bridge(U)`). 
> Idiomatically, though, we generally use initializers for value-preserving 
> conversions, so U(T) would be more consistent with the rest of the standard 
> library.
>  
> -Joe
>  
> > The ugly NSError pattern could be rewritten and migrated to:
> >  
> > do {
> > try something()
> > } catch let error {
> > handle(error `bridge` NSError)
> > }
> >  
> > Is such a change complicated, what do you think?
> >  
> > --
> > Adrian Zubarev
> > Sent with Airmail
> >  
> > Am 4. Mai 2016 bei 01:50:54, Joe Groff via swift-evolution 
> > (swift-evolution@swift.org) schrieb:
> >  
> > > Thanks everyone for the initial round of feedback. I've submitted a draft 
> > > proposal:
> > >  
> > > https://github.com/apple/swift-evolution/pull/289
> > > https://github.com/jckarter/swift-evolution/blob/remove-bridging-conversion-dynamic-casts/proposals/-remove-bridging-from-dynamic-casts.md
> > >  
> > > -Joe
> > > ___
> > > 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] UnsafeBytePointer API for In-Memory Layout

[Andrew Trick via swift-evolution]

> On May 9, 2016, at 1:16 PM, Joe Groff  wrote:
> 
> Andy, I think it's worth clarifying the primary purpose of this proposal. Our 
> main goal here is to provide a legal means for "type-punning" memory access. 
> Like C and C++, it's technically undefined behavior in Swift to cast an 
> UnsafePointer to an UnsafePointer of a different type and load a value 
> out of memory that's of a different type from what was stored there. We don't 
> take much advantage of this yet in Swift's optimizer, since we don't have 
> good alternative API. UnsafeBytePointer seeks to fill this gap by providing a 
> type that can safely do type-punned loads and stores.

Absolutely, that’s the main point. I’ll work on the proposal's language. But I 
should point out that the optimizer has taken advantage of UnsafePointer’s type 
for a long time. We’re only saved because when we convert UMP types, we usually 
pass the memory off to an external C function, which acts as a boundary to 
optimization.

The current proposal grew out of my auditing the standard library, attempting 
to weed out undefined behavior.

Also note that I initially wanted to propose a much less ambitious API that 
allowed type punning, but otherwise left UMP unchanged. However, I got some 
strong feedback early on that if converting UMP types leads to undefined 
behavior, then it should be prohibited in the API, unless the programming 
explicitly requests the conversion. I happen to agree with that feedback. Since 
you and others also wanted a more complete API for manual memory layout, I saw 
that as one solution to both problems.

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

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Joe Groff via swift-evolution]

> On May 9, 2016, at 2:18 PM, Andrew Trick  wrote:
> 
>> 
>> On May 9, 2016, at 1:20 PM, Joe Groff  wrote:
>> 
>> Regarding the UnsafeBytePointer API:
>> 
>>> struct UnsafeBytePointer : Hashable
>>> , _Pointer {
>>> 
>>>   
>>> let _rawValue: Builtin.
>>> RawPointer
>>> 
>>>   
>>> var hashValue: Int {...
>>> }
>>> 
>>>   
>>> init(_ : UnsafePointer
>>> )
>>>   
>>> init(_ : UnsafeMutablePointer
>>> )
>>>   
>>> init?(_ : UnsafePointer
>>> ?)
>>>   
>>> init?(_ : UnsafeMutablePointer
>>> ?)
>>> 
>>>   
>>> init(_ : OpaquePointer
>>> )
>>>   
>>> init?(_ : OpaquePointer
>>> ?)
>>> 
>>>   
>>> init?(bitPattern: Int
>>> )
>>>   
>>> init?(bitPattern: UInt
>>> )
>>> 
>>>   
>>> func load(_ : T.Type) ->
>>>  T
>>> 
>>>   
>>> @warn_unused_result
>>> 
>>>   
>>> init(allocatingBytes size: Int, alignedTo: Int
>>> )
>>> 
>>>   
>>> @warn_unused_result
>>> 
>>>   
>>> init(allocatingCapacity count: Int, of: T.Type
>>> )
>>> 
>>>   
>>> func deallocateBytes(_ size: Int, alignedTo: Int
>>> )
>>> 
>>>   
>>> func deallocateCapacity(_ num: Int, of: T.Type
>>> )
>>> 
>>>   
>>> // Returns a pointer one byte after the initialized memory.
>>> 
>>>   
>>> func initialize(with newValue: T, count: Int = 1) ->
>>>  UnsafeBytePointer
>>> 
>>>   
>>> // Returns a pointer one byte after the initialized memory.
>>> 
>>>   
>>> func initialize(from: UnsafePointer, count: Int) ->
>>>  UnsafeBytePointer
>>> 
>>>   
>>> func initializeBackward(from source: UnsafePointer, count: Int
>>> )
>>> 
>>>   
>>> func deinitialize(_ : T.Type, count: Int = 1
>>> )
>>> }
>>> 
>> 
>> Should we also have 'assign' methods, matching 'initialize'? Should 
>> 'deinitialize' be called 'destroy', matching 'UnsafeMutablePointer's API?
> 
> I was wondering if anyone would ask for ‘assign’. It presumes that you are 
> storing the same type of object that was previously stored in your buffer. I 
> didn’t want to proactively support that case because it’s a convenience and 
> not really consistent with the pointer being type punned. You can always call 
> deinitialize() first if you need to before calling ‘initialize'.

I see. I guess it makes sense that, once you've initialized as the new type, 
you can cast to UMP and type-safe-ly reassign via that interface.

>  I  used ‘deinitialize’ to be consistent with UnsafeMutablePointer.

My mistake, I hadn't noticed that 'destroy' was renamed there too.

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

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Andrew Trick via swift-evolution]

> On May 9, 2016, at 1:23 PM, Xiaodi Wu  wrote:
> 
> Along similar lines, with the indexing model change, isn't the following 
> outdated?

Yes. Thanks. I’m working on updating both the proposal and implementation.
-Andy

> 
> ```
> extension UnsafeBytePointer : RandomAccessIndex {
>   typealias Distance = Int
> 
>   func successor() -> UnsafeBytePointer
>   func predecessor() -> UnsafeBytePointer
>   func distance(to : UnsafeBytePointer) -> Int
>   func advanced(by : Int) -> UnsafeBytePointer
> }
> ```
> 
> 
> On Mon, May 9, 2016 at 3:20 PM, Joe Groff via swift-evolution 
> > wrote:
> Regarding the UnsafeBytePointer API:
> 
>> struct UnsafeBytePointer : Hashable, _Pointer {
>> 
>>   let _rawValue: Builtin.RawPointer
>> 
>>   var hashValue: Int {...}
>> 
>>   init(_ : UnsafePointer)
>>   init(_ : UnsafeMutablePointer)
>>   init?(_ : UnsafePointer?)
>>   init?(_ : UnsafeMutablePointer?)
>> 
>>   init(_ : OpaquePointer)
>>   init?(_ : OpaquePointer?)
>> 
>>   init?(bitPattern: Int)
>>   init?(bitPattern: UInt)
>> 
>>   func load(_ : T.Type) -> T
>> 
>>   @warn_unused_result
>>   init(allocatingBytes size: Int, alignedTo: Int)
>> 
>>   @warn_unused_result
>>   init(allocatingCapacity count: Int, of: T.Type)
>> 
>>   func deallocateBytes(_ size: Int, alignedTo: Int)
>> 
>>   func deallocateCapacity(_ num: Int, of: T.Type)
>> 
>>   // Returns a pointer one byte after the initialized memory.
>>   func initialize(with newValue: T, count: Int = 1) -> UnsafeBytePointer
>> 
>>   // Returns a pointer one byte after the initialized memory.
>>   func initialize(from: UnsafePointer, count: Int) -> UnsafeBytePointer
>> 
>>   func initializeBackward(from source: UnsafePointer, count: Int)
>> 
>>   func deinitialize(_ : T.Type, count: Int = 1)
>> }
> 
> Should we also have 'assign' methods, matching 'initialize'? Should 
> 'deinitialize' be called 'destroy', matching 'UnsafeMutablePointer's API?
> 
> -Joe
> 
> ___
> 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] UnsafeBytePointer API for In-Memory Layout

[Joe Groff via swift-evolution]

> On May 9, 2016, at 1:25 PM, Geordie Jay  wrote:
> 
> So what's in it for us as Swift devs?
> 
> It may be technically undefined behaviour (by that I think you mean there's 
> no real knowing what could happen), but it seems to be rampant throughout 
> pretty much all the C code I've come in contact with (I'm less familiar with 
> C++).

Undefined behavior means that the compiler can optimize as if it couldn't 
happen. For example, in this C code:

int foo(int *x, float *y) {
*x = 2;
*y = 3.0;
return *x;
}

the compiler will likely optimize 'foo' to always return 2, since it's allowed 
to assume its pointer parameters x and y are different types so don't alias, If 
code calls `foo` with aliasing pointers such as `foo(, (float*))`, it'll 
break.

> If we lose type information by calling a C API that takes a void pointer, how 
> can we hope to retrieve it in any safe way, other than saying "we assume with 
> good reason and hope to hell that this is what we say it is".

This doesn't change anything in that respect. The aliasing rules in C and Swift 
refer to the type of value that's dynamically stored in memory, not the static 
type of a pointer. It's legal to cast a pointer from T* to void* and back to 
T*, and load a T from the resulting pointer, so long as a T value resides in 
the referenced memory at the time the load occurs.

> And if we can't do that, what advantage does this proposal provide over what 
> we already have?

This API gives you a way to legally perform pointer type punning, when you do 
want to reinterpret memory as a different type. In C and C++ the only standard 
way to do so is to `memcpy`.

-Joe

> Joe Groff  schrieb am Mo., 9. Mai 2016 um 22:16:
> 
> > On May 9, 2016, at 12:38 PM, Geordie Jay via swift-evolution 
> >  wrote:
> >
> > I read this proposal and I'm a bit unsure what its purpose would be:
> >
> > Basically you want to prevent UnsafePointer(UnsafePointer) 
> > conversions and/or vice-versa? And you'd achieve this by replacing 
> > UnsafePointer with UnsafeBytePointer that has no bound pointer type?
> >
> > In one sense the change seems fine to me, but as someone who uses a lot of 
> > C APIs and a lot of CoreAudio/CoreMIDI in Swift already I can't really see 
> > what benefit it'd bring. Presumably we'd still want an option of converting 
> > UnsafeBytePointer to UnsafePointer for things like C 
> > function pointer callback "context"/"userInfo" uses, so it's not like we'd 
> > be preventing programmer error in that way.
> >
> > Call me conservative but to me the current system seems to work as well as 
> > it can. If anything it's already enough boilerplate going through hoops 
> > converting an UnsafeMutablePointer into a [Float] even when I know 
> > and the C API knows perfectly well what it actually contains... Would 
> > happily be convinced otherwise about this proposal though, I'm pretty new 
> > at all this.
> >
> > Geordie
> 
> > On May 9, 2016, at 12:57 PM, Guillaume Lessard via swift-evolution 
> >  wrote:
> >
> > I’m sympathetic to the elimination of UnsafePointer as general 
> > shorthand for an arbitrary pointer, but I lose the plot of this very long 
> > proposal. It seems to me that this increases API surface, yet everything I 
> > could do before, I could still do; it just involves more typing. What 
> > exactly does this make better?
> >
> > Cheers,
> > Guillaume Lessard
> 
> Andy, I think it's worth clarifying the primary purpose of this proposal. Our 
> main goal here is to provide a legal means for "type-punning" memory access. 
> Like C and C++, it's technically undefined behavior in Swift to cast an 
> UnsafePointer to an UnsafePointer of a different type and load a value 
> out of memory that's of a different type from what was stored there. We don't 
> take much advantage of this yet in Swift's optimizer, since we don't have 
> good alternative API. UnsafeBytePointer seeks to fill this gap by providing a 
> type that can safely do type-punned loads and stores.
> 
> -Joe

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

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Geordie Jay via swift-evolution]

So what's in it for us as Swift devs?

It may be technically undefined behaviour (by that I think you mean there's
no real knowing what could happen), but it seems to be rampant throughout
pretty much all the C code I've come in contact with (I'm less familiar
with C++).

If we lose type information by calling a C API that takes a void pointer,
how can we hope to retrieve it in any safe way, other than saying "we
assume with good reason and hope to hell that this is what we say it is".
And if we can't do that, what advantage does this proposal provide over
what we already have?
Joe Groff  schrieb am Mo., 9. Mai 2016 um 22:16:

>
> > On May 9, 2016, at 12:38 PM, Geordie Jay via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I read this proposal and I'm a bit unsure what its purpose would be:
> >
> > Basically you want to prevent UnsafePointer(UnsafePointer)
> conversions and/or vice-versa? And you'd achieve this by replacing
> UnsafePointer with UnsafeBytePointer that has no bound pointer type?
> >
> > In one sense the change seems fine to me, but as someone who uses a lot
> of C APIs and a lot of CoreAudio/CoreMIDI in Swift already I can't really
> see what benefit it'd bring. Presumably we'd still want an option of
> converting UnsafeBytePointer to UnsafePointer for things
> like C function pointer callback "context"/"userInfo" uses, so it's not
> like we'd be preventing programmer error in that way.
> >
> > Call me conservative but to me the current system seems to work as well
> as it can. If anything it's already enough boilerplate going through hoops
> converting an UnsafeMutablePointer into a [Float] even when I know
> and the C API knows perfectly well what it actually contains... Would
> happily be convinced otherwise about this proposal though, I'm pretty new
> at all this.
> >
> > Geordie
>
> > On May 9, 2016, at 12:57 PM, Guillaume Lessard via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I’m sympathetic to the elimination of UnsafePointer as general
> shorthand for an arbitrary pointer, but I lose the plot of this very long
> proposal. It seems to me that this increases API surface, yet everything I
> could do before, I could still do; it just involves more typing. What
> exactly does this make better?
> >
> > Cheers,
> > Guillaume Lessard
>
> Andy, I think it's worth clarifying the primary purpose of this proposal.
> Our main goal here is to provide a legal means for "type-punning" memory
> access. Like C and C++, it's technically undefined behavior in Swift to
> cast an UnsafePointer to an UnsafePointer of a different type and
> load a value out of memory that's of a different type from what was stored
> there. We don't take much advantage of this yet in Swift's optimizer, since
> we don't have good alternative API. UnsafeBytePointer seeks to fill this
> gap by providing a type that can safely do type-punned loads and stores.
>
> -Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Xiaodi Wu via swift-evolution]

Along similar lines, with the indexing model change, isn't the following
outdated?

```

extension UnsafeBytePointer : RandomAccessIndex {
  typealias Distance = Int

  func successor() -> UnsafeBytePointer
  func predecessor() -> UnsafeBytePointer
  func distance(to : UnsafeBytePointer) -> Int
  func advanced(by : Int) -> UnsafeBytePointer
}

```


On Mon, May 9, 2016 at 3:20 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

> Regarding the UnsafeBytePointer API:
>
> struct UnsafeBytePointer : Hashable, _Pointer {
>
>   let _rawValue: Builtin.RawPointer
>
>   var hashValue: Int {...}
>
>   init(_ : UnsafePointer)
>   init(_ : UnsafeMutablePointer)
>   init?(_ : UnsafePointer?)
>   init?(_ : UnsafeMutablePointer?)
>
>   init(_ : OpaquePointer)
>   init?(_ : OpaquePointer?)
>
>   init?(bitPattern: Int)
>   init?(bitPattern: UInt)
>
>   func load(_ : T.Type) -> T
>
>   @warn_unused_result
>   init(allocatingBytes size: Int, alignedTo: Int)
>
>   @warn_unused_result
>   init(allocatingCapacity count: Int, of: T.Type)
>
>   func deallocateBytes(_ size: Int, alignedTo: Int)
>
>   func deallocateCapacity(_ num: Int, of: T.Type)
>
>   // Returns a pointer one byte after the initialized memory.
>   func initialize(with newValue: T, count: Int = 1) -> UnsafeBytePointer
>
>   // Returns a pointer one byte after the initialized memory.
>   func initialize(from: UnsafePointer, count: Int) -> UnsafeBytePointer
>
>   func initializeBackward(from source: UnsafePointer, count: Int)
>
>   func deinitialize(_ : T.Type, count: Int = 1)
> }
>
>
> Should we also have 'assign' methods, matching 'initialize'? Should
> 'deinitialize' be called 'destroy', matching 'UnsafeMutablePointer's API?
>
> -Joe
>
> ___
> 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] UnsafeBytePointer API for In-Memory Layout

[Joe Groff via swift-evolution]

Regarding the UnsafeBytePointer API:

> struct UnsafeBytePointer : Hashable, _Pointer {
> 
>   let _rawValue: Builtin.RawPointer
> 
>   var hashValue: Int {...}
> 
>   init(_ : UnsafePointer)
>   init(_ : UnsafeMutablePointer)
>   init?(_ : UnsafePointer?)
>   init?(_ : UnsafeMutablePointer?)
> 
>   init(_ : OpaquePointer)
>   init?(_ : OpaquePointer?)
> 
>   init?(bitPattern: Int)
>   init?(bitPattern: UInt)
> 
>   func load(_ : T.Type) -> T
> 
>   @warn_unused_result
>   init(allocatingBytes size: Int, alignedTo: Int)
> 
>   @warn_unused_result
>   init(allocatingCapacity count: Int, of: T.Type)
> 
>   func deallocateBytes(_ size: Int, alignedTo: Int)
> 
>   func deallocateCapacity(_ num: Int, of: T.Type)
> 
>   // Returns a pointer one byte after the initialized memory.
>   func initialize(with newValue: T, count: Int = 1) -> UnsafeBytePointer
> 
>   // Returns a pointer one byte after the initialized memory.
>   func initialize(from: UnsafePointer, count: Int) -> UnsafeBytePointer
> 
>   func initializeBackward(from source: UnsafePointer, count: Int)
> 
>   func deinitialize(_ : T.Type, count: Int = 1)
> }

Should we also have 'assign' methods, matching 'initialize'? Should 
'deinitialize' be called 'destroy', matching 'UnsafeMutablePointer's API?

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

Re: [swift-evolution] Typealiases in protocols and protocol extensions

[Xiaodi Wu via swift-evolution]

Sorry--I'm not at all saying that I think there's a problem. As you asked,
I attempted to supply a contrived use case for a typealias declared in a
protocol having a more restricted scope than the protocol itself. I was
asking if it would be supported as part of your proposal.


On Mon, May 9, 2016 at 3:11 PM, David Hart  wrote:

> I don’t see a problem with your example. Because the typealias is
> fileprivate, it doesn’t exist as far as MyUsefulType is concerned. The same
> way the following works:
>
> ```
> class Base {
> private typealias Foo = Int
> func foo() -> Int {
> return Foo()
> }
> }
> ```
>
> Other file:
>
> ```
> class Derived: Base {
> typealias Foo = String
> func bar() -> String {
> return "Hello \(foo())"
> }
> }
> ```
>
> On 09 May 2016, at 10:37, Xiaodi Wu  wrote:
>
> On Mon, May 9, 2016 at 2:31 AM, David Hart  wrote:
>
>>
>> On 09 May 2016, at 09:16, Xiaodi Wu  wrote:
>>
>> One more thought here:
>>
>> It goes a long way to say "typealiases in protocols are to have the same
>> semantics as aliases outside protocols." I'm inclined to agree on that, but
>> I haven't thought it totally through.
>>
>> Now, I can have private typealiases outside protocols. Could I have
>> private typealiases inside protocols? They'd be handy for referencing types
>> while implementing default methods in protocol extensions and whatnot
>> without worrying about collisions with typealiases in conforming types…
>>
>>
>> Sounds like it should be allowed. I’ll add something about it in the
>> proposal. Could you give an example of what you mean by "without worrying
>> about collisions with typealiases in conforming types…”?
>>
>>
> I wonder if this takes things in an, um, interesting direction. Suppose I
> could have this (a contrived example--it may fall apart on further study):
>
> ```
> protocol MyUsefulProtocol {
>   associatedtype Storage : Collection
>   fileprivate typealias UniqueIdentifier = Storage.Index
>   func doUsefulThing() -> Storage
> }
>
> extension MyUsefulProtocol {
>   func doUsefulThing() -> Storage {
> // do something useful in this default implementation
> // use UniqueIdentifier internally here and only here
>   }
> }
> ```
>
> In a different file:
>
> ```
> struct MyUsefulType : MyUsefulProtocol {
>   /* I could do this if I wanted:
>   typealias UniqueIdentifier = A
>
>   More importantly, I could retroactively conform MyUsefulType
>   to MyUsefulProtocol even if they happen to have clashing
>   typealiases, which is great because the typealias in
>   MyUsefulProtocol is used for clarity and convenience inside
>   the default implementation and is irrelevant here
>   */
>   func doUsefulThing() -> Dictionary {
> // do something useful but different
> // from the default implementation
>   }
> }
> ```
>
> I wonder, though, if this is to be allowed, whether much the same could be
> achieved by instead allowing associatedtype declarations to have default
> values (for example: `associatedtype UniqueIdentifier : Equatable =
> Storage.Index`), at which point we might be one step away from going full
> circle and eliminating the distinction between associatedtypes and
> typealiases once again.
>
>
> On Mon, May 9, 2016 at 01:52 David Hart  wrote:
>>
>>> I understand that name clashing in those instances is important to
>>> discuss, but I still think it is slightly orthogonal to the proposal. Let
>>> me try to explain why.
>>>
>>> If typealises in protocols are to have the same semantics as alises
>>> outside protocols (as I think they should), then they don’t change anything
>>> about the rules of collision. For example, the problem already exists today
>>> with associated types:
>>>
>>> protocol Foo {
>>> associatedtype Inner: IntegerType
>>> func foo(inner: Inner)
>>> }
>>>
>>> protocol Bar {
>>> associatedtype Inner: FloatingPointType
>>> var inner: Inner { get }
>>> }
>>>
>>> struct FooBarImpl: Foo, Bar { // error: Type ‘FooBarImpl’ does not
>>> conform to protocol ‘Bar'
>>> func foo(inner: Int) {}
>>> var inner: Float
>>> }
>>>
>>> Type aliasing would not change anything about the fact that those
>>> collisions already exists in the language and are not very well handled:
>>> either they are meant to be forbidden but in that case we need better
>>> diagnostics, or we want to have a way to work around them. Perhaps you’d
>>> like to start a discussion around fixing that ?
>>>
>>> On 09 May 2016, at 08:06, Xiaodi Wu  wrote:
>>>
>>> I see your point that nothing breaks in the stdlib with your proposal
>>> alone. It's undeniably true--by construction!--that a purely additive
>>> feature, if never used, will not cause problems.
>>>
>>> That said, since the time that this feature was outlined in Doug's
>>> manifesto, I have been wondering how clashes such as the examples in my
>>> previous 

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Joe Groff via swift-evolution]

> On May 9, 2016, at 12:38 PM, Geordie Jay via swift-evolution 
>  wrote:
> 
> I read this proposal and I'm a bit unsure what its purpose would be:
> 
> Basically you want to prevent UnsafePointer(UnsafePointer) 
> conversions and/or vice-versa? And you'd achieve this by replacing 
> UnsafePointer with UnsafeBytePointer that has no bound pointer type?
> 
> In one sense the change seems fine to me, but as someone who uses a lot of C 
> APIs and a lot of CoreAudio/CoreMIDI in Swift already I can't really see what 
> benefit it'd bring. Presumably we'd still want an option of converting 
> UnsafeBytePointer to UnsafePointer for things like C function 
> pointer callback "context"/"userInfo" uses, so it's not like we'd be 
> preventing programmer error in that way.
> 
> Call me conservative but to me the current system seems to work as well as it 
> can. If anything it's already enough boilerplate going through hoops 
> converting an UnsafeMutablePointer into a [Float] even when I know and 
> the C API knows perfectly well what it actually contains... Would happily be 
> convinced otherwise about this proposal though, I'm pretty new at all this.
> 
> Geordie

> On May 9, 2016, at 12:57 PM, Guillaume Lessard via swift-evolution 
>  wrote:
> 
> I’m sympathetic to the elimination of UnsafePointer as general 
> shorthand for an arbitrary pointer, but I lose the plot of this very long 
> proposal. It seems to me that this increases API surface, yet everything I 
> could do before, I could still do; it just involves more typing. What exactly 
> does this make better?
> 
> Cheers,
> Guillaume Lessard

Andy, I think it's worth clarifying the primary purpose of this proposal. Our 
main goal here is to provide a legal means for "type-punning" memory access. 
Like C and C++, it's technically undefined behavior in Swift to cast an 
UnsafePointer to an UnsafePointer of a different type and load a value 
out of memory that's of a different type from what was stored there. We don't 
take much advantage of this yet in Swift's optimizer, since we don't have good 
alternative API. UnsafeBytePointer seeks to fill this gap by providing a type 
that can safely do type-punned loads and stores.

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

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

[Charles Srstka via swift-evolution]

> On May 6, 2016, at 2:04 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> The ugly NSError pattern could be rewritten and migrated to:
> 
> do {
>try something()
> } catch let error {
>handle(error `bridge` NSError)
> }
> 
> Is such a change complicated, what do you think?

I’ve made a pitch, "Consistent bridging for NSErrors at the language boundary”, 
which I believe would not only eliminate the need for “as” to contain bridging 
magic, but is also much less ugly than either the current pattern or the 
example above.

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016618.html
 


Charles

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

Re: [swift-evolution] Typealiases in protocols and protocol extensions

[David Hart via swift-evolution]

I don’t see a problem with your example. Because the typealias is fileprivate, 
it doesn’t exist as far as MyUsefulType is concerned. The same way the 
following works:

```
class Base {
private typealias Foo = Int
func foo() -> Int {
return Foo()
}
}
```

Other file:

```
class Derived: Base {
typealias Foo = String
func bar() -> String {
return "Hello \(foo())"
}
}
```

> On 09 May 2016, at 10:37, Xiaodi Wu  wrote:
> 
> On Mon, May 9, 2016 at 2:31 AM, David Hart  > wrote:
> 
>> On 09 May 2016, at 09:16, Xiaodi Wu > > wrote:
>> 
>> One more thought here:
>> 
>> It goes a long way to say "typealiases in protocols are to have the same 
>> semantics as aliases outside protocols." I'm inclined to agree on that, but 
>> I haven't thought it totally through.
>> 
>> Now, I can have private typealiases outside protocols. Could I have private 
>> typealiases inside protocols? They'd be handy for referencing types while 
>> implementing default methods in protocol extensions and whatnot without 
>> worrying about collisions with typealiases in conforming types…
> 
> Sounds like it should be allowed. I’ll add something about it in the 
> proposal. Could you give an example of what you mean by "without worrying 
> about collisions with typealiases in conforming types…”?
> 
> 
> I wonder if this takes things in an, um, interesting direction. Suppose I 
> could have this (a contrived example--it may fall apart on further study):
> 
> ```
> protocol MyUsefulProtocol {
>   associatedtype Storage : Collection
>   fileprivate typealias UniqueIdentifier = Storage.Index
>   func doUsefulThing() -> Storage
> }
> 
> extension MyUsefulProtocol {
>   func doUsefulThing() -> Storage {
> // do something useful in this default implementation
> // use UniqueIdentifier internally here and only here
>   }
> }
> ```
> 
> In a different file:
> 
> ```
> struct MyUsefulType : MyUsefulProtocol {
>   /* I could do this if I wanted:
>   typealias UniqueIdentifier = A
>   
>   More importantly, I could retroactively conform MyUsefulType
>   to MyUsefulProtocol even if they happen to have clashing
>   typealiases, which is great because the typealias in
>   MyUsefulProtocol is used for clarity and convenience inside
>   the default implementation and is irrelevant here
>   */
>   func doUsefulThing() -> Dictionary {
> // do something useful but different
> // from the default implementation
>   }
> }
> ```
> 
> I wonder, though, if this is to be allowed, whether much the same could be 
> achieved by instead allowing associatedtype declarations to have default 
> values (for example: `associatedtype UniqueIdentifier : Equatable = 
> Storage.Index`), at which point we might be one step away from going full 
> circle and eliminating the distinction between associatedtypes and 
> typealiases once again.
> 
> 
>> On Mon, May 9, 2016 at 01:52 David Hart > > wrote:
>> I understand that name clashing in those instances is important to discuss, 
>> but I still think it is slightly orthogonal to the proposal. Let me try to 
>> explain why.
>> 
>> If typealises in protocols are to have the same semantics as alises outside 
>> protocols (as I think they should), then they don’t change anything about 
>> the rules of collision. For example, the problem already exists today with 
>> associated types:
>> 
>> protocol Foo {
>> associatedtype Inner: IntegerType
>> func foo(inner: Inner)
>> }
>> 
>> protocol Bar {
>> associatedtype Inner: FloatingPointType
>> var inner: Inner { get }
>> }
>> 
>> struct FooBarImpl: Foo, Bar { // error: Type ‘FooBarImpl’ does not conform 
>> to protocol ‘Bar'
>> func foo(inner: Int) {}
>> var inner: Float
>> }
>> 
>> Type aliasing would not change anything about the fact that those collisions 
>> already exists in the language and are not very well handled: either they 
>> are meant to be forbidden but in that case we need better diagnostics, or we 
>> want to have a way to work around them. Perhaps you’d like to start a 
>> discussion around fixing that ?
>> 
>>> On 09 May 2016, at 08:06, Xiaodi Wu >> > wrote:
>>> 
>>> I see your point that nothing breaks in the stdlib with your proposal 
>>> alone. It's undeniably true--by construction!--that a purely additive 
>>> feature, if never used, will not cause problems.
>>> 
>>> That said, since the time that this feature was outlined in Doug's 
>>> manifesto, I have been wondering how clashes such as the examples in my 
>>> previous email are to be handled--i.e. what the rules of the language are 
>>> to be--which I think is certainly germane to your proposal. Can a 
>>> conforming type override a protocol typealias? Can a type conform to two 
>>> protocols with conflicting 

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Guillaume Lessard via swift-evolution]

I’m sympathetic to the elimination of UnsafePointer as general shorthand 
for an arbitrary pointer, but I lose the plot of this very long proposal. It 
seems to me that this increases API surface, yet everything I could do before, 
I could still do; it just involves more typing. What exactly does this make 
better?

Cheers,
Guillaume Lessard

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

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Geordie Jay via swift-evolution]

I read this proposal and I'm a bit unsure what its purpose would be:

Basically you want to prevent UnsafePointer(UnsafePointer)
conversions and/or vice-versa? And you'd achieve this by replacing
UnsafePointer with UnsafeBytePointer that has no bound pointer type?

In one sense the change seems fine to me, but as someone who uses a lot of
C APIs and a lot of CoreAudio/CoreMIDI in Swift already I can't really see
what benefit it'd bring. Presumably we'd still want an option of converting
UnsafeBytePointer to UnsafePointer for things like C
function pointer callback "context"/"userInfo" uses, so it's not like we'd
be preventing programmer error in that way.

Call me conservative but to me the current system seems to work as well as
it can. If anything it's already enough boilerplate going through hoops
converting an UnsafeMutablePointer into a [Float] even when I know
and the C API knows perfectly well what it actually contains... Would
happily be convinced otherwise about this proposal though, I'm pretty new
at all this.

Geordie
Andrew Trick via swift-evolution  schrieb am
Mo., 9. Mai 2016 um 20:15:

> Hello Swift evolution,
>
> I sent this to swift-dev last week. Sorry to post on two lists!
>
> Swift does a great job of protecting against undefined behavior--as long
> as you avoid "unsafe" APIs, that is. However, unsafe APIs are important for
> giving developers control over implementation details and performance.
> Naturally, the contract between unsafe APIs and the optimizer is crucial.
> When a developer uses an unsafe API, the rules governing safe, well-defined
> behavior must be clear. On the opposite end, the optimizer must know which
> assumptions it can make based on those rules. Simply saying that anything
> goes because "unsafe" is in the name is not helpful to this effort.
>
> For a long time, I've wanted these rules nailed down. We have more users
> taking advantage of advanced features, and more optimizations that take
> advantage of assumptions guided by the type system. This seems like a
> particularly good time to resolve UnsafePointer semantics, considering the
> type system and UnsafePointer work that's been going on recently. Strict
> aliasing is something I would like addressed. If we do nothing here, then
> we will end up by default inheriting C/C++ semantics, as with any language
> that relies on a C/C++ backend. In other words, developers will be forced
> to write code with technically undefined behavior and rely on the compiler
> to be smart enough to recognize and recover from common patterns. Or we can
> take advantage of this opportunity and instead adopt a sound memory model
> with respect to aliasing.
>
> This proposal is only an RFC at this point. I'm sending it out now to
> allow for plenty of time for discussion (or advance warning). Keep in mind
> that it could change considerably before it goes up for review.
>
> -Andy
>
>
> UnsafeBytePointer API for In-Memory Layout
>
>- Proposal: SE-
>
> 
>- Author(s): Andrew Trick 
>- Status: Awaiting review
>
> 
>- Review manager: TBD
>
>
> 
> Introduction
>
> UnsafePointer and UnsafeMutable refer to a typed region of memory, and
> the compiler must be able to assume that UnsafePointer element (Pointee)
> type is consistent with other access to the same memory. See proposed
> Type Safe Memory Access documentation
> .
> Consequently, inferred conversion between UnsafePointer element types
> exposes an easy way to abuse the type system. No alternative currently
> exists for manual memory layout and direct access to untyped memory, and
> that leads to an overuse of UnsafePointer. These uses of UnsafePointer,
> which depend on pointer type conversion, make accidental type punning
> likely. Type punning via UnsafePointer is semantically undefined behavior
> and de facto undefined behavior given the optimizer's long-time treatment
> of UnsafePointer.
>
> In this document, all mentions of UnsafePointer also apply to
> UnsafeMutablePointer.
>
> 
> Motivation
>
> To avoid accidental type punning, we should prohibit inferred conversion
> between UnsafePointer and UnsafePointer unless the target of the
> conversion is an untyped or nondereferenceable pointer (currently
> represented as UnsafePointer).
>
> To support this change we should introduce a new pointer type that does
> not bind the type of its Pointee. Such a new pointer type would provide
> an ideal foundation for an API that allows byte-wise pointer arithmetic and
> a legal, well-defined 

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

[Joe Groff via swift-evolution]

> On May 6, 2016, at 12:04 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Definitely a welcome change from me (+1). But this proposal makes me curious 
> about the impact on the `AnyObject` protocol?
> 
> let string = "foo"
> let nsString = string as AnyObject
> nsString.dynamicType // _NSCFConstantString.Type
> NSString().dynamicType // __NSCFConstantString.Type // there are two 
> different types? 
> 
> This sample won’t bridge anymore if SE-0083 will be accepted.

Right, you'd need to do NSString(string) as AnyObject to explicitly bridge.

> Can we also drop the @objc from `AnyObject` protocol and leave it as an 
> implicit protocol for classes? (Personally I’d rename `AnyObject` to 
> `AnyReference` if Swift will introduce other reference types.)

The @objc-ness of AnyObject is more or less an implementation detail. On Darwin 
platforms at least, AnyObject still has the magic ability to dispatch to all 
@objc methods, similar to `id` in Objective-C, which vaguely defends its 
@objc-ness. (If we're going to rename it, my own preference would be to drop 
the Any and just call it `Object`, since we don't put Any in any other protocol 
names.)

> This change might allow the replacement of the `class` keyword from protocols 
> with the implicit `AnyObject` protocol, which can be discussed in this 
> thread: Should we rename "class" when referring to   protocol conformance?
> 
> One more thing I’d like to ask: is there any possibility of adding a new 
> `bridge` keyword, which would allow explicit bridging to a different language 
> type (ObjC, etc. if there are any more languages we can bridge to [C or maybe 
> one day C++])?
> 
> T `bridge` U
> T? `bridge` U?

One could write `bridge` as a method in most cases; it doesn't need to be a 
keyword with special syntax, since you could write `T.bridge(U.self)` (or, if 
we accept https://github.com/apple/swift-evolution/pull/299, `T.bridge(U)`). 
Idiomatically, though, we generally use initializers for value-preserving 
conversions, so U(T) would be more consistent with the rest of the standard 
library.

-Joe

> The ugly NSError pattern could be rewritten and migrated to:
> 
> do {
>try something()
> } catch let error {
>handle(error `bridge` NSError)
> }
> 
> Is such a change complicated, what do you think?
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 4. Mai 2016 bei 01:50:54, Joe Groff via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> Thanks everyone for the initial round of feedback. I've submitted a draft 
>> proposal:
>> 
>> https://github.com/apple/swift-evolution/pull/289
>> https://github.com/jckarter/swift-evolution/blob/remove-bridging-conversion-dynamic-casts/proposals/-remove-bridging-from-dynamic-casts.md
>> 
>> -Joe
>> ___
>> 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] [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] [Pitch] Consistent bridging for NSErrors at the language boundary

[Charles Srstka via swift-evolution]

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 
>> place, if they have other code that wants to check these errors. In a 
>> pure-Swift program, checking against a particular error can often be done 
>> simply via an equality check. If the error has been converted to NSError via 
>> the 

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

[Erica Sadun via swift-evolution]

The pitch was not warmly received. If you want to pick it up and run with it, 
go ahead. 
https://gist.github.com/erica/fc66e6f6335750d737e5512797e8284a 


I have a running list of dead or deferred ideas here: 
https://gist.github.com/erica/9eae0d949297509ad86e


-- E

> On May 9, 2016, at 11:49 AM, Vladimir.S  wrote:
> 
> Hi Erica, could you clarify, what is state of this proposal and your plans 
> regarding it? I believe we certainly should make Swift more explicit 
> regarding what methods in type are required by the conformed protocol and 
> what methods are required(and which are 'optional') in protocol extensions.
> 
> Right now there is a discussion regarding 'optional' keyword("Modify optional 
> method semantics for swift"), and I remembered your proposal..
> 
> Probably 'optional' keyword for non-required methods in extension instead of 
> marking 'required' methods will looks better(as they are optional to the 
> protocol itself), what do you think?
> I.e.
> 
> protocol A {
>func foo()
>func bar()
>func blort()
>func gar()
> }
> 
> extension A {
>//required func blort() {} // Correct, required by `A`
>//func womble() {} // Correct, new method in extension
>//func gar() {} // Incorrect: Compiler says: add `required` keyword..
> 
>func blort() {} // Correct, was introduced in `A`
>optional func womble() {} // Correct, new(optional) method in extension
>optional func gar() {} // Incorrect: Compiler says: remove `optional`..
> }
> 
> struct B: A {
>required func foo() {} // Correct
>required func far() {} // Near miss. Compiler: rename method or drop 
> required keyword
>func bar() {} // Possible accidental name match. Compiler: rename method 
> or add required keyword
> 
>func womble() {} // ?? how this method should be 'marked' ??
> }
> 
> (But personally I think one *overload* keyword will do the job in both cases 
> - in extension and in type declaration)
> 
> Regarding this "func womble()" questions.. I think we need *at least* 
> compilation warning that *at the moment of compilation*, B.womble may(?) 
> conflicts with extension of A.womble.
> 
> Personaly I was not expecting to get the result of this code:
> 
> protocol A {
>  func a()
> }
> 
> extension A {
>   func b() { print("(b) in A") }
> }
> 
> struct C : A {
>func a() {}
>func b() { print("(b) in C") }
> }
> 
> var c : A = C()
> c.b()  // (b) in A
> 
> 
>> On 28.04.2016 19:53, Erica Sadun via swift-evolution wrote:
>>> Draft. Criticism and suggestions both welcome. -- E
>>> 
>>> 
>>>  Requiring Proactive Overrides for Default Protocol Implementations
>>> 
>>>  * Proposal: tbd
>>>  * Author(s): Erica Sadun 
>>>  * Status: tbd
>>>  * Review manager: tbd2
>>> 
>>> 
>>> 
>>> Introduction
>>> 
>>> 
>>> This proposal enhances protocol implementation safety. It incorporates two
>>> keywords that cooperate with compiler checks to limit "near miss"
>>> implementation errors and accidental member overrides.
>>> 
>>> /This proposal was discussed on the Swift Evolution list in the [Pitch]
>>> Requiring proactive overrides for default protocol implementations.
>>>  thread/
>>> 
>>> 
>>> 
>>> Motivation
>>> 
>>> 
>>> The proposal introduces a mandatory |required| keyword that marks members
>>> as fulfiling protocol requirements. This expansion reduces the risk of
>>> near-miss implementations (for example, adding |thud(x:
>>> Double)| when |thud(x: Float)|is required), provides in-line documentation
>>> of why the member has been included, thereby enhancing the code-level
>>> documentation at the implementation point, and supports compile-time checks
>>> for protocol conformance.
>>> 
>>> This proposal extends the |override| keyword to protocol conformance. The
>>> Swift Programming Language describes the way subclass methods must override
>>> implementations established in superclasses. /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./
>>> 
>>> Adding an |override| requirement expands this cautious approach to
>>> protocols. Developers must override implementations inherited from protocol
>>> extensions with the |override| keyword. And the compiler will flag uses
>>> of |override| where member implementations do not, in fact, override an
>>> existing implementation. The keyword prevents accidental overrides, where a
>>> sensible member name conflicts with signatures established in the protocol
>>> 

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Andrew Trick via swift-evolution]

> On May 9, 2016, at 8:34 AM, Matthew Johnson  wrote:
> 
>> I would prefer to wait until indirect structs and improved CoW support have 
>> had more discussion.
> 
> I've been thinking a lot about Dave's desire to "mandate" that value semantic 
> types must be value types and allowing us to use reference identity for 
> equality of reference types.  I would support that if these features were in 
> place so I think shifting to those topics is a good next step for this 
> discussion.  
> 
> Along those lines, I've been thinking about a proposal to allow the indirect 
> modifier on any property that has a value type.  It may also be useful to 
> allow the indirect modifier directly on struct and enum to allow type authors 
> to indicate that all instances should be indirect.  Do you think it would it 
> be worthwhile to pursue this proposal now?
> 
> Can you elaborate on what you have in mind with regards to improved CoW 
> support?  Is there any chance of doing something here in Swift 3?

I don’t have anything specific planned for CoW support in Swift 3, otherwise I 
would have started a separate thread :)
-Andy___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Thorsten Seitz via swift-evolution]

> Am 03.05.2016 um 13:42 schrieb Hans Huck via swift-evolution 
> :
> 
> Thorsten Seitz via swift-evolution  writes:
>> 
>> -1
>> 
>> I don't see the need for special syntax where a method can be easily used
> and is more general.
>> 
>> -Thorsten 
>> 
> 
> That, dear Thorsten, is a non-argument. Why? Let's see, how about "I don't
> see the need for a For-loop where a While-loop can be easily used and is
> more general.“

I meant „more general“ in the sense of allowing reuse (of these methods) in 
other contexts and of allowing more powerful abstractions (in this case 
expressed by simple methods on sequences) to be used easily.
For the same reason I would not rate Swift’s for-loop as more general than 
Scala’s for-loop which is more akin to Haskell’s monadic do-notation. More 
basic or more low level, yes, but not more general.

-Thorsten


> 
> The "special syntax" summarized below by Vladimir is absolutely justified,
> because
> 
> a) Zipf's Law and


> b) forcing people to use convoluted OOP notation for basic, iterative tasks
> is simply offensive.

> 
> -- Hans
> 
> 
>>> Am 18.04.2016 um 17:28 schrieb Vladimir.S via swift-evolution
>  swift.org>:
>>> 
>>> On 15.04.2016 3:57, Hans Huck via swift-evolution wrote:
 Anyway, why not just make it .step() then, like in Ruby?
 
 Instead of a "by" keyword, I'd be happy with syntactic sugar in the
> form of
 
 for i in p1..>> 
>>> As for 'step' word: It seems like for now IMO this is the best
> suggestion : very explicit, anyone knows what
>> "step" means especially in context of loop, clear that "step" belongs to
> for-in construction(not to
>> range itself).
>>> 
>>> for i in 0..<10 step 2 {
>>> }
>>> 
>>> for i in 0..<10 step -2 {
>>> }
>>> 
>>> for i in 0.1..<10.5 step 0.5 {
>>> }
>>> 
>>> all are mapped to needed ranges/intervals under the hood
>>> Do you want some custom Range-specific methods to provide steps for loop
> - no problems, use what you need.
>> But don't force any of us to use (0..<10).striding(by:2) for myriads of
> simple loops in our code.
>>> 
>>> I want to see such constructions in our Swift. Who is with me ? :)
> 
> 
> ___
> 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] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

[Rainer Brockerhoff via swift-evolution]

On 5/9/16 14:01, Joe Groff via swift-evolution wrote:
> 
>> On May 8, 2016, at 10:30 PM, Morten Bek Ditlevsen  wrote:
>>
>> This would be an excellent solution to the issue.
>> Do you know if there are any existing plans for something like the 
>> DecimalLiteralConvertible?
> 
> Not that I know of. Someone would have to submit a proposal.
> 
>>
>> Another thought:
>> Would it make sense to have the compiler warn about float literal precision 
>> issues?
>> Initialization of two different variables with the exact same literal value 
>> could yield different precision results if one had a FloatLiteralType 
>> aliased to Float80 and the other aliased to Float.
> 
> That's definitely a possibility. We already have machinery in place to raise 
> errors when integer literals overflow Int* types, and we could do something 
> similar for float literals that have excessive precision.

For compilation, it would probably be overkill to show even a warning
for non-representable numbers like 0.1 assigned to a binary
floating-point type, but perhaps such a warning might be acceptable in a
playground?


>> On Fri, May 6, 2016 at 6:46 PM Joe Groff  wrote:
>>
>>> On May 6, 2016, at 9:42 AM, Stephen Canon  wrote:
>>>
>>>
 On May 6, 2016, at 12:41 PM, Joe Groff via swift-evolution 
  wrote:

>
> On May 6, 2016, at 2:24 AM, Morten Bek Ditlevsen via swift-evolution 
>  wrote:
>
> Currently, in order to conform to FloatLiteralConvertible you need to 
> implement
> an initializer accepting a floatLiteral of the typealias: 
> FloatLiteralType.
> However, this typealias can only be Double, Float, Float80 and other 
> built-in
> floating point types (to be honest, I do not know the exact limitation 
> since I have
> not been able to read find this in the documentation).
>
> These floating point types have precision limitations that are not 
> necessarily
> present in the type that you are making FloatLiteralConvertible.
>
> Let’s imagine a CurrencyAmount type that uses an NSDecimalNumber as the
> representation of the value:
>
>
> public struct CurrencyAmount {
> public let value: NSDecimalNumber
> // .. other important currency-related stuff ..
> }
>
> extension CurrencyAmount: FloatLiteralConvertible {
> public typealias FloatLiteralType = Double
>
> public init(floatLiteral amount: FloatLiteralType) {
>   print(amount.debugDescription)
>   value = NSDecimalNumber(double: amount)
> }
> }
>
> let a: CurrencyAmount = 99.99
>
>
> The printed value inside the initializer is 99.985 - so the 
> value
> has lost precision already in the intermediary Double representation.
>
> I know that there is also an issue with the NSDecimalNumber double 
> initializer,
> but this is not the issue that we are seeing here.
>
>
> One suggestion for a solution to this issue would be to allow the
> FloatLiteralType to be aliased to a String.  In this case the compiler 
> should
> parse the float literal token: 99.99 to a String and use that as input 
> for the
> FloatLiteralConvertible initializer.
>
> This would mean that arbitrary literal precisions are allowed for
> FloatLiteralConvertibles that implement their own parsing of a String 
> value.
>
> For instance, if the CurrencyAmount used a FloatLiteralType aliased to 
> String we
> would have:
>
> extension CurrencyAmount: FloatLiteralConvertible {
> public typealias FloatLiteralType = String
>
> public init(floatLiteral amount: FloatLiteralType) {
>   value = NSDecimalNumber(string: amount)
> }
> }
>
> and the precision would be the same as creating an NSDecimalNumber from a
> String:
>
> let a: CurrencyAmount = 1.001
>
> print(a.value.debugDescription)
>
> Would give: 1.001
>
>
> How does that sound? Is it completely irrational to allow the use of 
> Strings as
> the intermediary representation of float literals?
> I think that it makes good sense, since it allows for arbitrary precision.
>
> Please let me know what you think.

 Like Dmitri said, a String is not a particularly efficient intermediate 
 representation. For common machine numeric types, we want it to be 
 straightforward for the compiler to constant-fold literals down to 
 constants in the resulting binary. For floating-point literals, I think we 
 could achieve this by changing the protocol to "deconstruct" the literal 
 value into integer significand and exponent, something like this:

 // A type that can be initialized from a decimal literal such as
 // 

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

[Vladimir.S via swift-evolution]

Hi Erica, could you clarify, what is state of this proposal and your plans 
regarding it? I believe we certainly should make Swift more explicit 
regarding what methods in type are required by the conformed protocol and 
what methods are required(and which are 'optional') in protocol extensions.


Right now there is a discussion regarding 'optional' keyword("Modify 
optional method semantics for swift"), and I remembered your proposal..


Probably 'optional' keyword for non-required methods in extension instead 
of marking 'required' methods will looks better(as they are optional to the 
protocol itself), what do you think?

I.e.

protocol A {
func foo()
func bar()
func blort()
func gar()
}

extension A {
//required func blort() {} // Correct, required by `A`
//func womble() {} // Correct, new method in extension
//func gar() {} // Incorrect: Compiler says: add `required` keyword..

func blort() {} // Correct, was introduced in `A`
optional func womble() {} // Correct, new(optional) method in extension
optional func gar() {} // Incorrect: Compiler says: remove `optional`..
}

struct B: A {
required func foo() {} // Correct
required func far() {} // Near miss. Compiler: rename method or drop 
required keyword
func bar() {} // Possible accidental name match. Compiler: rename 
method or add required keyword


func womble() {} // ?? how this method should be 'marked' ??
}

(But personally I think one *overload* keyword will do the job in both 
cases - in extension and in type declaration)


Regarding this "func womble()" questions.. I think we need *at least* 
compilation warning that *at the moment of compilation*, B.womble may(?) 
conflicts with extension of A.womble.


Personaly I was not expecting to get the result of this code:

protocol A {
  func a()
}

extension A {
   func b() { print("(b) in A") }
}

struct C : A {
func a() {}
func b() { print("(b) in C") }
}

var c : A = C()
c.b()  // (b) in A



On 28.04.2016 19:53, Erica Sadun via swift-evolution wrote:

Draft. Criticism and suggestions both welcome. -- E


  Requiring Proactive Overrides for Default Protocol Implementations

  * Proposal: tbd
  * Author(s): Erica Sadun 
  * Status: tbd
  * Review manager: tbd2



Introduction


This proposal enhances protocol implementation safety. It incorporates two
keywords that cooperate with compiler checks to limit "near miss"
implementation errors and accidental member overrides.

/This proposal was discussed on the Swift Evolution list in the [Pitch]
Requiring proactive overrides for default protocol implementations.
 thread/



Motivation


The proposal introduces a mandatory |required| keyword that marks members
as fulfiling protocol requirements. This expansion reduces the risk of
near-miss implementations (for example, adding |thud(x:
Double)| when |thud(x: Float)|is required), provides in-line documentation
of why the member has been included, thereby enhancing the code-level
documentation at the implementation point, and supports compile-time checks
for protocol conformance.

This proposal extends the |override| keyword to protocol conformance. The
Swift Programming Language describes the way subclass methods must override
implementations established in superclasses. /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./

Adding an |override| requirement expands this cautious approach to
protocols. Developers must override implementations inherited from protocol
extensions with the |override| keyword. And the compiler will flag uses
of |override| where member implementations do not, in fact, override an
existing implementation. The keyword prevents accidental overrides, where a
sensible member name conflicts with signatures established in the protocol
conformance and forces users to proactively select a version in favor of
existing protocol extensions.



Detail

Design

  * The |override| keyword is extended to protocol inheritance, and when
used prefers the overridden behavior to the default behavior.
  * Swift will prefer an overridden implementation in preference in reverse
hierarchical order: type extensions take precedence over type
declarations over protocol extensions over protocol declarations
(assuming protocol declarations eventually adopt default
implementations).
  * The |required| keyword marks a member as satisfying a protocol
requirement, 

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

[Tony Parker via swift-evolution]

Hi Matthew (and others),

> On May 9, 2016, at 9:03 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution 
>>  wrote:
>> 
>> This is exactly the way I see it, too. Many people are coming to Swift
>> and immediately decrying the language because it doesn't have built-in
>> support for regex, date parsing, collections beyond the built-in 3,
>> etc., when it in fact has a rich tapestry of things from Foundation.
>> 
>> While I agree with many of the points made in the thread, I think we're
>> missing the forest for the trees. Foundation is the best at many of the
>> things it does on any platform. This is in spite of many of the points
>> made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
>> It *does* have crufty edges.
>> 
>> Foundation not having a super-Swifty API is a solvable problem over
>> time, of which this is a first step down that road. Revamping the
>> Foundation API in the Swift 3 timeframe is not a solvable problem.
> 
> I agree with everything you say here.  My only concern is trying to ensure we 
> don't take steps today that will make it difficult to implement the best 
> design down the road.  

It’s true that Foundation is the foundation of the Objective-C stack. However, 
while some see this as a weakness, I see it as a great opportunity. The role of 
this library puts it in a unique spot as a leverage point: low enough level to 
be used in nearly all applications on all platforms, but high enough level to 
establish API and patterns that you see across the SDK.

The idea of leaving existing API behind somehow by keeping the prefix means 
that the leverage would be gone. With all existing API in terms of those 
existing types, any new types are effectively unused in all API above 
Foundation. We would need to introduce conversion methods to move between the 
two types (if that is even possible).

If, instead, we evolve the existing API to be better for Swift, then we benefit 
the entire stack without having a boil-the-ocean type of adoption problem. 
Therefore, we have already made the decision that we are not going to invent an 
entirely new set of a fundamental types but to instead iteratively improve the 
API of the ones we have.

- Tony

> 
>> 
>> Cheers
>>  Zach Waldowski
>>  z...@waldowski.me
>> 
>>> On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:
>>> If I am coming to Swift as a new user (possibly as a first language,
>>> even) without any prior Objective-C experience and very little knowledge
>>> of the long history of Foundation, the NS prefix, etc, this is going to
>>> feel worse than a little out of place - it will feel downright wrong,
>>> broken, and confusing to see these weird NS prefixes on some seemingly
>>> “standard” classes and not on others.
>>> 
>>> I’m +1 for removing the NS and evolving forward from there - let’s not
>>> create a confusing tangle of old and new that is navigable only by those
>>> with knowledge of the esoteric.
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
 On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution 
  wrote:
 
 I have mixed feelings about this; while I agree that prefixing names isn’t 
 a good fit for Swift, at the same time that’s kind of the appeal of it. 
 Assuming that Foundation will eventually be replaced by a more Swift-like 
 alternative, or will be incrementally reworked, I think it makes sense for 
 it to feel a little weird to use as it is right now.
 
 The NS prefix makes it clear that this is something different, something 
 not originally designed with Swift in mind, and in a way that’s a good 
 thing. I know in my own case it makes me instinctively shy away from it, 
 and actually encourages me to wrap NS constructs in something more 
 Swift-like for convenience.
 
> On 6 May 2016, at 21:52, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> Thanks to all of you for your feedback on SE-0069 (Foundation Value 
> Types). I’m back again with more information on another part of our plan 
> to integrate Foundation API into Swift: dropping the NS prefix.
> 
> When we originally proposed this as part of the API guidelines document 
> (SE-0023, 
> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md),
>  we took a very broad approach to which classes would drop their prefix. 
> This time, we’ve narrowed the scope considerably, plus taken advantage of 
> the ability to nest types inside classes to further reduce the 
> possibility of introducing conflicting names.
> 
> I’ve written up a draft of the proposal, which includes an extensive 
> section on motivation plus a list of changes. Please take a look and let 
> 

Re: [swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

[Joe Groff via swift-evolution]

> On May 9, 2016, at 10:12 AM, Jacob Bandes-Storch  wrote:
> 
> Maybe I made a mistake when testing, but I thought I was able to convert a 
> negative Int to a large UInt by going through NSNumber (it didn't return nil 
> from the as? cast).

It's less bad if you're able to do this explicitly. It was the *implicit* 
conversion behavior we were concerned about.

-Joe

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

Re: [swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

[Jacob Bandes-Storch via swift-evolution]

Maybe I made a mistake when testing, but I thought I was able to convert a
negative Int to a large UInt by going through NSNumber (it didn't return
nil from the as? cast).
On Mon, May 9, 2016 at 10:11 AM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On May 7, 2016, at 1:23 PM, Zach Waldowski via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > On Fri, May 6, 2016, at 11:20 PM, Charles Srstka via swift-evolution
> wrote:
> >> let int = num as? Int // 5
> >> let float = num as? Float // 5
> >> let int32 = num as? Int32 // nil!
> > That specific behavior with Int32 seems to be an oversight in the stdlib.
>
> It wasn't an oversight. At the time of Swift 1.0, bridging a type implied
> bidirectional implicit conversions, and if *every* integer type were
> bridgeable, it would be possible to unsafely implicitly convert between any
> two integer types by hopping through NSNumber. Now that we've eliminated
> these implicit conversions, we could consider bridging more types. Do you
> want to start another thread to discuss that idea?
>
> -Joe
> ___
> 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] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

[Joe Groff via swift-evolution]

> On May 7, 2016, at 1:23 PM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> On Fri, May 6, 2016, at 11:20 PM, Charles Srstka via swift-evolution wrote:
>> let int = num as? Int // 5
>> let float = num as? Float // 5
>> let int32 = num as? Int32 // nil!
> That specific behavior with Int32 seems to be an oversight in the stdlib.

It wasn't an oversight. At the time of Swift 1.0, bridging a type implied 
bidirectional implicit conversions, and if *every* integer type were 
bridgeable, it would be possible to unsafely implicitly convert between any two 
integer types by hopping through NSNumber. Now that we've eliminated these 
implicit conversions, we could consider bridging more types. Do you want to 
start another thread to discuss that idea?

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

Re: [swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

[Joe Groff via swift-evolution]

> On May 6, 2016, at 8:20 PM, Charles Srstka  wrote:
> 
>> On May 6, 2016, at 3:15 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>>> On May 6, 2016, at 12:21 PM, Jacob Bandes-Storch via swift-evolution 
>>>  wrote:
>>> 
>>> Does this affect the ability to use "x as? Int" (and similar) when x is an 
>>> NSNumber?
>> 
>> No, this only affects compile-time implicit conversions. I proposed changing 
>> the runtime behavior of dynamic casts in SE-0083:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md
> 
> I’d just like to throw in that the ability to use “x as? Int” when x is an 
> NSNumber is terrible.
> 
> let num: AnyObject = NSNumber(int: 5)
> 
> let int = num as? Int // 5
> let float = num as? Float // 5
> let int32 = num as? Int32 // nil!
> 
> Completely unexpected failure, and you’ll never know about it until runtime.

My pitch to eliminate this casting behavior got pulled as SE-0083, up for 
review this week:

https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md

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

Re: [swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

[Joe Groff via swift-evolution]

> On May 8, 2016, at 10:30 PM, Morten Bek Ditlevsen  wrote:
> 
> This would be an excellent solution to the issue.
> Do you know if there are any existing plans for something like the 
> DecimalLiteralConvertible?

Not that I know of. Someone would have to submit a proposal.

> 
> Another thought:
> Would it make sense to have the compiler warn about float literal precision 
> issues?
> Initialization of two different variables with the exact same literal value 
> could yield different precision results if one had a FloatLiteralType aliased 
> to Float80 and the other aliased to Float.

That's definitely a possibility. We already have machinery in place to raise 
errors when integer literals overflow Int* types, and we could do something 
similar for float literals that have excessive precision.

-Joe

> 
> On Fri, May 6, 2016 at 6:46 PM Joe Groff  wrote:
> 
> > On May 6, 2016, at 9:42 AM, Stephen Canon  wrote:
> >
> >
> >> On May 6, 2016, at 12:41 PM, Joe Groff via swift-evolution 
> >>  wrote:
> >>
> >>>
> >>> On May 6, 2016, at 2:24 AM, Morten Bek Ditlevsen via swift-evolution 
> >>>  wrote:
> >>>
> >>> Currently, in order to conform to FloatLiteralConvertible you need to 
> >>> implement
> >>> an initializer accepting a floatLiteral of the typealias: 
> >>> FloatLiteralType.
> >>> However, this typealias can only be Double, Float, Float80 and other 
> >>> built-in
> >>> floating point types (to be honest, I do not know the exact limitation 
> >>> since I have
> >>> not been able to read find this in the documentation).
> >>>
> >>> These floating point types have precision limitations that are not 
> >>> necessarily
> >>> present in the type that you are making FloatLiteralConvertible.
> >>>
> >>> Let’s imagine a CurrencyAmount type that uses an NSDecimalNumber as the
> >>> representation of the value:
> >>>
> >>>
> >>> public struct CurrencyAmount {
> >>> public let value: NSDecimalNumber
> >>> // .. other important currency-related stuff ..
> >>> }
> >>>
> >>> extension CurrencyAmount: FloatLiteralConvertible {
> >>> public typealias FloatLiteralType = Double
> >>>
> >>> public init(floatLiteral amount: FloatLiteralType) {
> >>>   print(amount.debugDescription)
> >>>   value = NSDecimalNumber(double: amount)
> >>> }
> >>> }
> >>>
> >>> let a: CurrencyAmount = 99.99
> >>>
> >>>
> >>> The printed value inside the initializer is 99.985 - so the 
> >>> value
> >>> has lost precision already in the intermediary Double representation.
> >>>
> >>> I know that there is also an issue with the NSDecimalNumber double 
> >>> initializer,
> >>> but this is not the issue that we are seeing here.
> >>>
> >>>
> >>> One suggestion for a solution to this issue would be to allow the
> >>> FloatLiteralType to be aliased to a String.  In this case the compiler 
> >>> should
> >>> parse the float literal token: 99.99 to a String and use that as input 
> >>> for the
> >>> FloatLiteralConvertible initializer.
> >>>
> >>> This would mean that arbitrary literal precisions are allowed for
> >>> FloatLiteralConvertibles that implement their own parsing of a String 
> >>> value.
> >>>
> >>> For instance, if the CurrencyAmount used a FloatLiteralType aliased to 
> >>> String we
> >>> would have:
> >>>
> >>> extension CurrencyAmount: FloatLiteralConvertible {
> >>> public typealias FloatLiteralType = String
> >>>
> >>> public init(floatLiteral amount: FloatLiteralType) {
> >>>   value = NSDecimalNumber(string: amount)
> >>> }
> >>> }
> >>>
> >>> and the precision would be the same as creating an NSDecimalNumber from a
> >>> String:
> >>>
> >>> let a: CurrencyAmount = 1.001
> >>>
> >>> print(a.value.debugDescription)
> >>>
> >>> Would give: 1.001
> >>>
> >>>
> >>> How does that sound? Is it completely irrational to allow the use of 
> >>> Strings as
> >>> the intermediary representation of float literals?
> >>> I think that it makes good sense, since it allows for arbitrary precision.
> >>>
> >>> Please let me know what you think.
> >>
> >> Like Dmitri said, a String is not a particularly efficient intermediate 
> >> representation. For common machine numeric types, we want it to be 
> >> straightforward for the compiler to constant-fold literals down to 
> >> constants in the resulting binary. For floating-point literals, I think we 
> >> could achieve this by changing the protocol to "deconstruct" the literal 
> >> value into integer significand and exponent, something like this:
> >>
> >> // A type that can be initialized from a decimal literal such as
> >> // `1.1` or `2.3e5`.
> >> protocol DecimalLiteralConvertible {
> >>  // The integer type used to represent the significand and exponent of the 
> >> value.
> >>  typealias Component: IntegerLiteralConvertible
> >>
> >>  // Construct a value equal to `decimalSignificand * 10**decimalExponent`.

Re: [swift-evolution] Modify optional method semantics for swift

[Carlos Rodríguez Domínguez via swift-evolution]

That’s a very interesting approach. My approach was intended to facilitate the 
transition from @objc optionals. However, your proposal is good for me too. 

> El 9 may 2016, a las 18:54, Vladimir.S  escribió:
> 
> IMO if a class conforms to some protocol, this *should* means that methods of 
> the protocol is implemented exactly inside that class(or in superclasses). In 
> your suggestion, *optional* methods will be implemented "somewhere" outside 
> of conformed class. IMO protocol should not depend on any default 
> implementation.
> 
> I have another suggestion: introduce 'optional' keyword to mark methods of 
> protocol extension which(methods) were not declared in protocol. I.e. :
> 
> protocol A {
>  func a()
>  func b()
> }
> 
> extension A {
>  *optional* func c() {..} // explicitely tells us that this method is 
> optional and was not introduces in the A protocol itself
> 
>  func a() {..} // default implementation for "existed" method in A protocol
> }
> 
> On 09.05.2016 19:15, Carlos Rodríguez Domínguez via swift-evolution wrote:
>> Rationale:
>> 
>> As a everybody knows, “optional” keyword is present in swift solely to
>> maintain compatibility with objective-c protocols. Optional methods in
>> protocols are neither a swift capability, nor a wanted one. In fact,
>> proposal [0070] intends to begin the transition to an optionals-free
>> language. In fact, optionals, as presented by objective-c, are a manner to
>> avoid interface segregation.
>> 
>> Nonetheless, in many occasions, optionals are used to model customized
>> behavior vs default one. For instance, if you take a look at the
>> documentation of UITableViewDataSource or delegate, you’ll see that
>> optional methods are not required, since the framework provides a default
>> behavior that can be customized by implementing the corresponding optional
>> methods.
>> 
>> Consequently, is most cases, optional methods in objective-c are a means to
>> replace the semantics of default protocol method implementations, as
>> supported through extensions in swift.
>> 
>> Therefore, my proposal is to modify the semantics of “optional” keyword in
>> swift to mean: “you must provide a default implementation of this method
>> through an extension”. This is different from objective-c semantics, which
>> mean “the implementation of this method may not be provided”.
>> 
>> Detailed design:
>> 
>> In this proposal, protocols could be defined like this:
>> 
>> protocol Datasource {
>> associatedtype Element
>> 
>> var count:Int {get}
>> func elementAt(index:Int) -> Element
>> optional func color(elementIndex:Int) -> UIColor
>> }
>> 
>> However, this definition enforces the developer to create an extension a
>> provide a default implementation of the optional method:
>> 
>> extension Datasource {
>> func color(elementIndex:Int) -> UIColor {
>> return UIColor.blackColor()
>> }
>> }
>> 
>> In this way, what we are achieving is that we are avoiding objective-c
>> optional semantics (which is a way to avoid interface segregation), but we
>> are making explicit that a method in a protocol requires a default
>> implementation, thus not requiring the developer to re-implement the method
>> in any entity adopting the protocol (as it currently happens when we
>> provide a default method implementation). Moreover, we are making explicit
>> that a certain protocol method has a default implementation, which can be
>> confusing right now.
>> 
>> Note that in this proposal, the intention is to keep both "@objc optional”
>> and simply “optional” keywords, to highlight both semantics. However, in
>> order to avoid @objc optional semantics as much as possible (to be able to
>> remove it in a future swift release), new annotations could be incorporated
>> to optional methods in objective-c code, to specify the default returned
>> value. For instance, the annotations could be like this:
>> 
>> @protocol Datasource
>> -(NSInteger) numberOfElements;
>> -(NSObject*) elementAtIndex:(NSInteger)index;
>> 
>> @optional
>> -(UIColor*) colorOfElementAtIndex:(NSInteger)index
>> __attribute__((swift_default_value(“UIColor.blackColor()")));
>> @end
>> 
>> Note that this annotation also allows to better understand the default
>> behavior in case the method is not implemented without reading the
>> documentation. This annotation should produce a swift code similar to the
>> above one.
>> 
>> 
>> 
>> ___
>> 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] Modify optional method semantics for swift

[Vladimir.S via swift-evolution]

IMO if a class conforms to some protocol, this *should* means that methods 
of the protocol is implemented exactly inside that class(or in 
superclasses). In your suggestion, *optional* methods will be implemented 
"somewhere" outside of conformed class. IMO protocol should not depend on 
any default implementation.


I have another suggestion: introduce 'optional' keyword to mark methods of 
protocol extension which(methods) were not declared in protocol. I.e. :


protocol A {
  func a()
  func b()
}

extension A {
  *optional* func c() {..} // explicitely tells us that this method is 
optional and was not introduces in the A protocol itself


  func a() {..} // default implementation for "existed" method in A protocol
}

On 09.05.2016 19:15, Carlos Rodríguez Domínguez via swift-evolution wrote:

Rationale:

As a everybody knows, “optional” keyword is present in swift solely to
maintain compatibility with objective-c protocols. Optional methods in
protocols are neither a swift capability, nor a wanted one. In fact,
proposal [0070] intends to begin the transition to an optionals-free
language. In fact, optionals, as presented by objective-c, are a manner to
avoid interface segregation.

Nonetheless, in many occasions, optionals are used to model customized
behavior vs default one. For instance, if you take a look at the
documentation of UITableViewDataSource or delegate, you’ll see that
optional methods are not required, since the framework provides a default
behavior that can be customized by implementing the corresponding optional
methods.

Consequently, is most cases, optional methods in objective-c are a means to
replace the semantics of default protocol method implementations, as
supported through extensions in swift.

Therefore, my proposal is to modify the semantics of “optional” keyword in
swift to mean: “you must provide a default implementation of this method
through an extension”. This is different from objective-c semantics, which
mean “the implementation of this method may not be provided”.

Detailed design:

In this proposal, protocols could be defined like this:

protocol Datasource {
associatedtype Element

var count:Int {get}
func elementAt(index:Int) -> Element
optional func color(elementIndex:Int) -> UIColor
}

However, this definition enforces the developer to create an extension a
provide a default implementation of the optional method:

extension Datasource {
func color(elementIndex:Int) -> UIColor {
return UIColor.blackColor()
}
}

In this way, what we are achieving is that we are avoiding objective-c
optional semantics (which is a way to avoid interface segregation), but we
are making explicit that a method in a protocol requires a default
implementation, thus not requiring the developer to re-implement the method
in any entity adopting the protocol (as it currently happens when we
provide a default method implementation). Moreover, we are making explicit
that a certain protocol method has a default implementation, which can be
confusing right now.

Note that in this proposal, the intention is to keep both "@objc optional”
and simply “optional” keywords, to highlight both semantics. However, in
order to avoid @objc optional semantics as much as possible (to be able to
remove it in a future swift release), new annotations could be incorporated
to optional methods in objective-c code, to specify the default returned
value. For instance, the annotations could be like this:

@protocol Datasource
-(NSInteger) numberOfElements;
-(NSObject*) elementAtIndex:(NSInteger)index;

@optional
-(UIColor*) colorOfElementAtIndex:(NSInteger)index
__attribute__((swift_default_value(“UIColor.blackColor()")));
@end

Note that this annotation also allows to better understand the default
behavior in case the method is not implemented without reading the
documentation. This annotation should produce a swift code similar to the
above one.



___
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] Dropping NS Prefix in Foundation

[Austin Zheng via swift-evolution]

In addition to the points that have been raised, it's my opinion that some
of the stuff in Foundation should really be implemented in the stdlib in
the future (for example, collections that weakly reference their items, and
a native binary data blob type). The fact that the delineation between what
goes in the stdlib and what goes in Foundation is the result of historical
happenstance does not really sit well with me. I think that Foundation's
evolution should be done with this in mind, such that in the future certain
Foundation classes might be implemented as stubs built on top of native
data structures, with additional functionality for legacy compatibility
(sort of like how String works today).

Best,
Austin

On Mon, May 9, 2016 at 9:03 AM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> > On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > This is exactly the way I see it, too. Many people are coming to Swift
> > and immediately decrying the language because it doesn't have built-in
> > support for regex, date parsing, collections beyond the built-in 3,
> > etc., when it in fact has a rich tapestry of things from Foundation.
> >
> > While I agree with many of the points made in the thread, I think we're
> > missing the forest for the trees. Foundation is the best at many of the
> > things it does on any platform. This is in spite of many of the points
> > made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
> > It *does* have crufty edges.
> >
> > Foundation not having a super-Swifty API is a solvable problem over
> > time, of which this is a first step down that road. Revamping the
> > Foundation API in the Swift 3 timeframe is not a solvable problem.
>
> I agree with everything you say here.  My only concern is trying to ensure
> we don't take steps today that will make it difficult to implement the best
> design down the road.
>
> >
> > Cheers
> >   Zach Waldowski
> >   z...@waldowski.me
> >
> >> On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:
> >> If I am coming to Swift as a new user (possibly as a first language,
> >> even) without any prior Objective-C experience and very little knowledge
> >> of the long history of Foundation, the NS prefix, etc, this is going to
> >> feel worse than a little out of place - it will feel downright wrong,
> >> broken, and confusing to see these weird NS prefixes on some seemingly
> >> “standard” classes and not on others.
> >>
> >> I’m +1 for removing the NS and evolving forward from there - let’s not
> >> create a confusing tangle of old and new that is navigable only by those
> >> with knowledge of the esoteric.
> >>
> >> l8r
> >> Sean
> >>
> >>
> >>> On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I have mixed feelings about this; while I agree that prefixing names
> isn’t a good fit for Swift, at the same time that’s kind of the appeal of
> it. Assuming that Foundation will eventually be replaced by a more
> Swift-like alternative, or will be incrementally reworked, I think it makes
> sense for it to feel a little weird to use as it is right now.
> >>>
> >>> The NS prefix makes it clear that this is something different,
> something not originally designed with Swift in mind, and in a way that’s a
> good thing. I know in my own case it makes me instinctively shy away from
> it, and actually encourages me to wrap NS constructs in something more
> Swift-like for convenience.
> >>>
>  On 6 May 2016, at 21:52, Tony Parker via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  Hi everyone,
> 
>  Thanks to all of you for your feedback on SE-0069 (Foundation Value
> Types). I’m back again with more information on another part of our plan to
> integrate Foundation API into Swift: dropping the NS prefix.
> 
>  When we originally proposed this as part of the API guidelines
> document (SE-0023,
> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md),
> we took a very broad approach to which classes would drop their prefix.
> This time, we’ve narrowed the scope considerably, plus taken advantage of
> the ability to nest types inside classes to further reduce the possibility
> of introducing conflicting names.
> 
>  I’ve written up a draft of the proposal, which includes an extensive
> section on motivation plus a list of changes. Please take a look and let me
> know what you think. We’ll start a formal review period soon.
> 
> 
> https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/-drop-foundation-ns.md
> 
>  Thanks again for your help,
>  - Tony
> 
>  ___
>  swift-evolution mailing list
>  swift-evolution@swift.org
>  https://lists.swift.org/mailman/listinfo/swift-evolution
> 

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

[Joe Groff via swift-evolution]

> On May 6, 2016, at 7:24 PM, Jose Cheyo Jimenez  wrote:
> 
> Hi Joe, 
> 
> Would I still be able to cast an AnyObject to a String or Array etc?

You would do so via constructors rather than using `as?`, something like 
String(bridging: object).

-Joe

> I am thinking about working with JSON files and using the Apple JSON Parser. 
> 
> Thanks
> 
> 
> 
>> On May 3, 2016, at 4:50 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> Thanks everyone for the initial round of feedback. I've submitted a draft 
>> proposal:
>> 
>> https://github.com/apple/swift-evolution/pull/289
>> https://github.com/jckarter/swift-evolution/blob/remove-bridging-conversion-dynamic-casts/proposals/-remove-bridging-from-dynamic-casts.md
>> 
>> -Joe
>> ___
>> 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] Modify optional method semantics for swift

[Carlos Rodríguez Domínguez via swift-evolution]

Rationale:

As a everybody knows, “optional” keyword is present in swift solely to maintain 
compatibility with objective-c protocols. Optional methods in protocols are 
neither a swift capability, nor a wanted one. In fact, proposal [0070] intends 
to begin the transition to an optionals-free language. In fact, optionals, as 
presented by objective-c, are a manner to avoid interface segregation.

Nonetheless, in many occasions, optionals are used to model customized behavior 
vs default one. For instance, if you take a look at the documentation of 
UITableViewDataSource or delegate, you’ll see that optional methods are not 
required, since the framework provides a default behavior that can be 
customized by implementing the corresponding optional methods.

Consequently, is most cases, optional methods in objective-c are a means to 
replace the semantics of default protocol method implementations, as supported 
through extensions in swift.

Therefore, my proposal is to modify the semantics of “optional” keyword in 
swift to mean: “you must provide a default implementation of this method 
through an extension”. This is different from objective-c semantics, which mean 
“the implementation of this method may not be provided”.

Detailed design:

In this proposal, protocols could be defined like this:

protocol Datasource {
associatedtype Element

var count:Int {get}
func elementAt(index:Int) -> Element
optional func color(elementIndex:Int) -> UIColor
}

However, this definition enforces the developer to create an extension a 
provide a default implementation of the optional method:

extension Datasource {
func color(elementIndex:Int) -> UIColor {
return UIColor.blackColor()
}
}

In this way, what we are achieving is that we are avoiding objective-c optional 
semantics (which is a way to avoid interface segregation), but we are making 
explicit that a method in a protocol requires a default implementation, thus 
not requiring the developer to re-implement the method in any entity adopting 
the protocol (as it currently happens when we provide a default method 
implementation). Moreover, we are making explicit that a certain protocol 
method has a default implementation, which can be confusing right now.

Note that in this proposal, the intention is to keep both "@objc optional” and 
simply “optional” keywords, to highlight both semantics. However, in order to 
avoid @objc optional semantics as much as possible (to be able to remove it in 
a future swift release), new annotations could be incorporated to optional 
methods in objective-c code, to specify the default returned value. For 
instance, the annotations could be like this:

@protocol Datasource
-(NSInteger) numberOfElements;
-(NSObject*) elementAtIndex:(NSInteger)index;

@optional
-(UIColor*) colorOfElementAtIndex:(NSInteger)index 
__attribute__((swift_default_value(“UIColor.blackColor()")));
@end

Note that this annotation also allows to better understand the default behavior 
in case the method is not implemented without reading the documentation. This 
annotation should produce a swift code similar to the above one.

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

Re: [swift-evolution] unums in Swift?

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 9, 2016, at 10:44 AM, Stephen Canon  wrote:
> 
> What do you find interesting about them?

As an app developer I'm not even remotely a numerics expert so my understanding 
is probably superficial.  The link I posted gave me the impression that they 
would avoid the errors that accumulate in floating point arithmetic.

> 
> I haven’t spent more than a few hours reading about them (and the definition 
> of “unum” seems to be a moving target, so I’m not sure that it would have 
> been useful to study them further), but my rough thoughts are:
> 
> - SORN are a cute alternative to intervals, but only feasible with 
> *extremely* low precision formats.
> 
> - For very low precision needs, fixed point or indexed numbers or lossy 
> compression seem like better options for most cases.
> 
> - For “typical” precision and dynamic range needs, hardware floating-point 
> (possibly with a compressed storage format) is just as useful and orders of 
> magnitude faster.
> 
> - For limited dynamic range applications, fixed-point formats seem like a 
> much better option (there’s a good opportunity here for library work to make 
> using fixed-point arithmetic less error prone).
> 
> - For very high dynamic range applications, fixed-point logarithms or 
> level-index numbers seem like a better option.
> 
> Unums are a cute way to mostly unify these ideas into a single type, but that 
> doesn’t actually seem like a good idea to me.  This is very much going to be 
> a jack-of-all-trades, master-of-none situation.

Makes sense.  Thanks for sharing your thoughts!

> 
> That said, they are an *interesting* idea, so I wouldn’t discourage anyone 
> from investigating them.
> 
> – Steve
> 
>> On May 7, 2016, at 3:08 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> Unums sound very interesting 
>> (http://ubiquity.acm.org/article.cfm?id=2913029).  I'm wondering if anyone 
>> working on numerics in Swift has considered an implementation in the 
>> standard library.
>> 
>> Matthew
>> 
>> Sent from my iPad
>> ___
>> 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] Dropping NS Prefix in Foundation

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> This is exactly the way I see it, too. Many people are coming to Swift
> and immediately decrying the language because it doesn't have built-in
> support for regex, date parsing, collections beyond the built-in 3,
> etc., when it in fact has a rich tapestry of things from Foundation.
> 
> While I agree with many of the points made in the thread, I think we're
> missing the forest for the trees. Foundation is the best at many of the
> things it does on any platform. This is in spite of many of the points
> made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
> It *does* have crufty edges.
> 
> Foundation not having a super-Swifty API is a solvable problem over
> time, of which this is a first step down that road. Revamping the
> Foundation API in the Swift 3 timeframe is not a solvable problem.

I agree with everything you say here.  My only concern is trying to ensure we 
don't take steps today that will make it difficult to implement the best design 
down the road.  

> 
> Cheers
>   Zach Waldowski
>   z...@waldowski.me
> 
>> On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:
>> If I am coming to Swift as a new user (possibly as a first language,
>> even) without any prior Objective-C experience and very little knowledge
>> of the long history of Foundation, the NS prefix, etc, this is going to
>> feel worse than a little out of place - it will feel downright wrong,
>> broken, and confusing to see these weird NS prefixes on some seemingly
>> “standard” classes and not on others.
>> 
>> I’m +1 for removing the NS and evolving forward from there - let’s not
>> create a confusing tangle of old and new that is navigable only by those
>> with knowledge of the esoteric.
>> 
>> l8r
>> Sean
>> 
>> 
>>> On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution 
>>>  wrote:
>>> 
>>> I have mixed feelings about this; while I agree that prefixing names isn’t 
>>> a good fit for Swift, at the same time that’s kind of the appeal of it. 
>>> Assuming that Foundation will eventually be replaced by a more Swift-like 
>>> alternative, or will be incrementally reworked, I think it makes sense for 
>>> it to feel a little weird to use as it is right now.
>>> 
>>> The NS prefix makes it clear that this is something different, something 
>>> not originally designed with Swift in mind, and in a way that’s a good 
>>> thing. I know in my own case it makes me instinctively shy away from it, 
>>> and actually encourages me to wrap NS constructs in something more 
>>> Swift-like for convenience.
>>> 
 On 6 May 2016, at 21:52, Tony Parker via swift-evolution 
  wrote:
 
 Hi everyone,
 
 Thanks to all of you for your feedback on SE-0069 (Foundation Value 
 Types). I’m back again with more information on another part of our plan 
 to integrate Foundation API into Swift: dropping the NS prefix.
 
 When we originally proposed this as part of the API guidelines document 
 (SE-0023, 
 https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md),
  we took a very broad approach to which classes would drop their prefix. 
 This time, we’ve narrowed the scope considerably, plus taken advantage of 
 the ability to nest types inside classes to further reduce the possibility 
 of introducing conflicting names.
 
 I’ve written up a draft of the proposal, which includes an extensive 
 section on motivation plus a list of changes. Please take a look and let 
 me know what you think. We’ll start a formal review period soon.
 
 https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/-drop-foundation-ns.md
 
 Thanks again for your help,
 - Tony
 
 ___
 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] unums in Swift?

[Stephen Canon via swift-evolution]

What do you find interesting about them?

I haven’t spent more than a few hours reading about them (and the definition of 
“unum” seems to be a moving target, so I’m not sure that it would have been 
useful to study them further), but my rough thoughts are:

- SORN are a cute alternative to intervals, but only feasible with *extremely* 
low precision formats.

- For very low precision needs, fixed point or indexed numbers or lossy 
compression seem like better options for most cases.

- For “typical” precision and dynamic range needs, hardware floating-point 
(possibly with a compressed storage format) is just as useful and orders of 
magnitude faster.

- For limited dynamic range applications, fixed-point formats seem like a much 
better option (there’s a good opportunity here for library work to make using 
fixed-point arithmetic less error prone).

- For very high dynamic range applications, fixed-point logarithms or 
level-index numbers seem like a better option.

Unums are a cute way to mostly unify these ideas into a single type, but that 
doesn’t actually seem like a good idea to me.  This is very much going to be a 
jack-of-all-trades, master-of-none situation.

That said, they are an *interesting* idea, so I wouldn’t discourage anyone from 
investigating them.

– Steve

> On May 7, 2016, at 3:08 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Unums sound very interesting 
> (http://ubiquity.acm.org/article.cfm?id=2913029).  I'm wondering if anyone 
> working on numerics in Swift has considered an implementation in the standard 
> library.
> 
> Matthew
> 
> Sent from my iPad
> ___
> 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] Dropping NS Prefix in Foundation

[Sean Heber via swift-evolution]

If I am coming to Swift as a new user (possibly as a first language, even) 
without any prior Objective-C experience and very little knowledge of the long 
history of Foundation, the NS prefix, etc, this is going to feel worse than a 
little out of place - it will feel downright wrong, broken, and confusing to 
see these weird NS prefixes on some seemingly “standard” classes and not on 
others.

I’m +1 for removing the NS and evolving forward from there - let’s not create a 
confusing tangle of old and new that is navigable only by those with knowledge 
of the esoteric.

l8r
Sean


> On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution 
>  wrote:
> 
> I have mixed feelings about this; while I agree that prefixing names isn’t a 
> good fit for Swift, at the same time that’s kind of the appeal of it. 
> Assuming that Foundation will eventually be replaced by a more Swift-like 
> alternative, or will be incrementally reworked, I think it makes sense for it 
> to feel a little weird to use as it is right now.
> 
> The NS prefix makes it clear that this is something different, something not 
> originally designed with Swift in mind, and in a way that’s a good thing. I 
> know in my own case it makes me instinctively shy away from it, and actually 
> encourages me to wrap NS constructs in something more Swift-like for 
> convenience.
> 
>> On 6 May 2016, at 21:52, Tony Parker via swift-evolution 
>>  wrote:
>> 
>> Hi everyone,
>> 
>> Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). 
>> I’m back again with more information on another part of our plan to 
>> integrate Foundation API into Swift: dropping the NS prefix.
>> 
>> When we originally proposed this as part of the API guidelines document 
>> (SE-0023, 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md),
>>  we took a very broad approach to which classes would drop their prefix. 
>> This time, we’ve narrowed the scope considerably, plus taken advantage of 
>> the ability to nest types inside classes to further reduce the possibility 
>> of introducing conflicting names.
>> 
>> I’ve written up a draft of the proposal, which includes an extensive section 
>> on motivation plus a list of changes. Please take a look and let me know 
>> what you think. We’ll start a formal review period soon.
>> 
>> https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/-drop-foundation-ns.md
>> 
>> Thanks again for your help,
>> - Tony
>> 
>> ___
>> 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] [Pitch] Require tuple conversions to be explicit when labels don't match

[Xiaodi Wu via swift-evolution]

Hmm. I'm also having second thoughts about that Fix-It. I wonder if the
"fix" that's automatically provided is little more than "press here to make
the red thingy go away and do nothing else."

The way I see it, if the error is restricted to mismatched labels, then the
presumption is that someone got the order of the labels wrong. So the error
is basically: "Hey, we think you accidentally swapped your labels. Do you
want us to fix it?" And the default fix, which some people are guaranteed
to choose without even reading the error very carefully, shouldn't be
"Leave the labels swapped even though it looks wrong, and just rewrite that
line so the error disappears!"
On Mon, May 9, 2016 at 05:09 Xiaodi Wu  wrote:

> Two more points to be made:
>
> First, there are types where current behavior allowing implicit erasure
> and affixing of labels is a definite win. Consider:
>
> ```
> typealias CartesianCoordinate = (x: Int, y: Int)
> let c: CartesianCoordinate = (0, 1)
> print(c.x)
>
> typealias PolarCoordinate = (r: Double, theta: Double)
> let p: PolarCoordinate = (0.0, M_PI)
> print(p.theta)
> ```
>
> Second, your examples involving pattern matching are not correct. Since
> it's a tuple *pattern*, you'll find that `let (right: e, left: f) = (left:
> 1, right: 2)` has the same effect as writing `let (left: f, right: e) =
> (left: 1, right: 2)`. Which is to say, left goes with left and right goes
> with right irrespective of the order of labels on the LHS.
>
>
> On Mon, May 9, 2016 at 4:00 AM, Xiaodi Wu  wrote:
>
>> Also--I didn't read this carefully enough in your initial example--I
>> disagree that either (left: Int, right: Int) to (Int, Int) or vice versa
>> should require explicit casting, and I think previous conversations on the
>> topic showed that at least some on the list felt the same way.
>>
>> Mismatched labels, yes, because IMO it's alarming without a more explicit
>> indication of intent to assume that a user intends to swap labels going
>> from (left: Int, right: Int) to (right: Int, left: Int). But to work around
>> that restriction, I should be able to erase labels and affix new ones
>> without using "as", since no unintentional label swapping can occur in
>> either direction.
>>
>>
>> On Mon, May 9, 2016 at 2:57 AM, Xiaodi Wu  wrote:
>>
>>> Hmm, not as sure about that one. To my mind it's a clear expression of
>>> intent there. You're saying you know what the labels are and you're
>>> choosing not to repeat them. I think it should be on you if you express
>>> that intent and you're just plain wrong.
>>>
>>>
>>> On Mon, May 9, 2016 at 2:32 AM, Jacob Bandes-Storch 
>>> wrote:
>>>
 ... and one might also want to require labels when passing values *to*
 a labeled tuple:

 func foo() -> (left: Int, right: Int) {
 return (3, 4)  // error: conversion between tuple types '(Int,
 Int)' and '(left: Int, right: Int)' requires explicit 'as' operator
 }

 I've personally been bitten by a typo of this sort (mistakenly swapping
 the values) before.
 Jacob

 On Mon, May 9, 2016 at 12:23 AM, Xiaodi Wu  wrote:

> A sensible solution, IMO. Error with Fix-It when attempting to convert
> implicitly between tuples with mismatched labels.
>
> On Mon, May 9, 2016 at 01:47 Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> There was some previous discussion under "[Discussion] Enforce
>> argument labels on tuples
>> ".
>>
>> Halfway through the thread, Haravikk clearly stated the key point:
>>
>> On Thu, Apr 21, 2016 at 12:14 AM, Haravikk via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I think the important thing to remember is that the label check is
>>> intended to prevent cases like this:
>>> let a:(left:Int, right:Int) = (1, 2)
>>> var b:(right:Int, left:Int) = a
>>> While the two tuples are compatible by type, the meaning of the
>>> values may differ due to the different labels; in this case the
>>> values are represented in a different order that a developer should 
>>> have to
>>> explicitly reverse to ensure they aren’t making a mistake, or they could
>>> represent radically different concepts altogether.
>>
>>
>>
>> I agree there's a potential for confusion here, and I suggest we
>> should add an error (or warning) imploring the user to make the 
>> conversion
>> explicit, when the source tuple is labeled:
>>
>> func foo() -> (left: Int, right: Int) { return (3, 4) }
>>
>> let (left: a, right: b) = foo()  // ok, labels match
>>
>> var x = 0, y = 0
>> (left: x, right: y) = (1, 3)  // ok, source is unlabeled
>>
>> let (c, d) = foo()
>> // 

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

[Haravikk via swift-evolution]

I have mixed feelings about this; while I agree that prefixing names isn’t a 
good fit for Swift, at the same time that’s kind of the appeal of it. Assuming 
that Foundation will eventually be replaced by a more Swift-like alternative, 
or will be incrementally reworked, I think it makes sense for it to feel a 
little weird to use as it is right now.

The NS prefix makes it clear that this is something different, something not 
originally designed with Swift in mind, and in a way that’s a good thing. I 
know in my own case it makes me instinctively shy away from it, and actually 
encourages me to wrap NS constructs in something more Swift-like for 
convenience.

> On 6 May 2016, at 21:52, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). 
> I’m back again with more information on another part of our plan to integrate 
> Foundation API into Swift: dropping the NS prefix.
> 
> When we originally proposed this as part of the API guidelines document 
> (SE-0023, 
> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md),
>  we took a very broad approach to which classes would drop their prefix. This 
> time, we’ve narrowed the scope considerably, plus taken advantage of the 
> ability to nest types inside classes to further reduce the possibility of 
> introducing conflicting names.
> 
> I’ve written up a draft of the proposal, which includes an extensive section 
> on motivation plus a list of changes. Please take a look and let me know what 
> you think. We’ll start a formal review period soon.
> 
> https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/-drop-foundation-ns.md
> 
> Thanks again for your help,
> - Tony
> 
> ___
> 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] Require tuple conversions to be explicit when labels don't match

[Xiaodi Wu via swift-evolution]

Also--I didn't read this carefully enough in your initial example--I
disagree that either (left: Int, right: Int) to (Int, Int) or vice versa
should require explicit casting, and I think previous conversations on the
topic showed that at least some on the list felt the same way.

Mismatched labels, yes, because IMO it's alarming without a more explicit
indication of intent to assume that a user intends to swap labels going
from (left: Int, right: Int) to (right: Int, left: Int). But to work around
that restriction, I should be able to erase labels and affix new ones
without using "as", since no unintentional label swapping can occur in
either direction.


On Mon, May 9, 2016 at 2:57 AM, Xiaodi Wu  wrote:

> Hmm, not as sure about that one. To my mind it's a clear expression of
> intent there. You're saying you know what the labels are and you're
> choosing not to repeat them. I think it should be on you if you express
> that intent and you're just plain wrong.
>
>
> On Mon, May 9, 2016 at 2:32 AM, Jacob Bandes-Storch 
> wrote:
>
>> ... and one might also want to require labels when passing values *to* a
>> labeled tuple:
>>
>> func foo() -> (left: Int, right: Int) {
>> return (3, 4)  // error: conversion between tuple types '(Int,
>> Int)' and '(left: Int, right: Int)' requires explicit 'as' operator
>> }
>>
>> I've personally been bitten by a typo of this sort (mistakenly swapping
>> the values) before.
>> Jacob
>>
>> On Mon, May 9, 2016 at 12:23 AM, Xiaodi Wu  wrote:
>>
>>> A sensible solution, IMO. Error with Fix-It when attempting to convert
>>> implicitly between tuples with mismatched labels.
>>>
>>> On Mon, May 9, 2016 at 01:47 Jacob Bandes-Storch via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 There was some previous discussion under "[Discussion] Enforce
 argument labels on tuples
 ".

 Halfway through the thread, Haravikk clearly stated the key point:

 On Thu, Apr 21, 2016 at 12:14 AM, Haravikk via swift-evolution <
 swift-evolution@swift.org> wrote:

> I think the important thing to remember is that the label check is
> intended to prevent cases like this:
> let a:(left:Int, right:Int) = (1, 2)
> var b:(right:Int, left:Int) = a
> While the two tuples are compatible by type, the meaning of the
> values may differ due to the different labels; in this case the
> values are represented in a different order that a developer should have 
> to
> explicitly reverse to ensure they aren’t making a mistake, or they could
> represent radically different concepts altogether.



 I agree there's a potential for confusion here, and I suggest we should
 add an error (or warning) imploring the user to make the conversion
 explicit, when the source tuple is labeled:

 func foo() -> (left: Int, right: Int) { return (3, 4) }

 let (left: a, right: b) = foo()  // ok, labels match

 var x = 0, y = 0
 (left: x, right: y) = (1, 3)  // ok, source is unlabeled

 let (c, d) = foo()
 // error: conversion between tuple types '(left: Int, right: Int)'
 and '(Int, Int)' requires explicit 'as' operator
 // suggested fix: "let (c, d) = foo() as (Int, Int)"

 let (right: e, left: f) = foo()
 // error: conversion between tuple types '(left: Int, right: Int)'
 and '(right: Int, left: Int)' requires explicit 'as' operator
 // suggested fix: "let (right: e, left: f) = foo() as (right: Int,
 left: Int)"


 Thoughts?

 Jacob
 ___
 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] Typealiases in protocols and protocol extensions

[Xiaodi Wu via swift-evolution]

On Mon, May 9, 2016 at 2:31 AM, David Hart  wrote:

>
> On 09 May 2016, at 09:16, Xiaodi Wu  wrote:
>
> One more thought here:
>
> It goes a long way to say "typealiases in protocols are to have the same
> semantics as aliases outside protocols." I'm inclined to agree on that, but
> I haven't thought it totally through.
>
> Now, I can have private typealiases outside protocols. Could I have
> private typealiases inside protocols? They'd be handy for referencing types
> while implementing default methods in protocol extensions and whatnot
> without worrying about collisions with typealiases in conforming types…
>
>
> Sounds like it should be allowed. I’ll add something about it in the
> proposal. Could you give an example of what you mean by "without worrying
> about collisions with typealiases in conforming types…”?
>
>
I wonder if this takes things in an, um, interesting direction. Suppose I
could have this (a contrived example--it may fall apart on further study):

```
protocol MyUsefulProtocol {
  associatedtype Storage : Collection
  fileprivate typealias UniqueIdentifier = Storage.Index
  func doUsefulThing() -> Storage
}

extension MyUsefulProtocol {
  func doUsefulThing() -> Storage {
// do something useful in this default implementation
// use UniqueIdentifier internally here and only here
  }
}
```

In a different file:

```
struct MyUsefulType : MyUsefulProtocol {
  /* I could do this if I wanted:
  typealias UniqueIdentifier = A

  More importantly, I could retroactively conform MyUsefulType
  to MyUsefulProtocol even if they happen to have clashing
  typealiases, which is great because the typealias in
  MyUsefulProtocol is used for clarity and convenience inside
  the default implementation and is irrelevant here
  */
  func doUsefulThing() -> Dictionary {
// do something useful but different
// from the default implementation
  }
}
```

I wonder, though, if this is to be allowed, whether much the same could be
achieved by instead allowing associatedtype declarations to have default
values (for example: `associatedtype UniqueIdentifier : Equatable =
Storage.Index`), at which point we might be one step away from going full
circle and eliminating the distinction between associatedtypes and
typealiases once again.


On Mon, May 9, 2016 at 01:52 David Hart  wrote:
>
>> I understand that name clashing in those instances is important to
>> discuss, but I still think it is slightly orthogonal to the proposal. Let
>> me try to explain why.
>>
>> If typealises in protocols are to have the same semantics as alises
>> outside protocols (as I think they should), then they don’t change anything
>> about the rules of collision. For example, the problem already exists today
>> with associated types:
>>
>> protocol Foo {
>> associatedtype Inner: IntegerType
>> func foo(inner: Inner)
>> }
>>
>> protocol Bar {
>> associatedtype Inner: FloatingPointType
>> var inner: Inner { get }
>> }
>>
>> struct FooBarImpl: Foo, Bar { // error: Type ‘FooBarImpl’ does not
>> conform to protocol ‘Bar'
>> func foo(inner: Int) {}
>> var inner: Float
>> }
>>
>> Type aliasing would not change anything about the fact that those
>> collisions already exists in the language and are not very well handled:
>> either they are meant to be forbidden but in that case we need better
>> diagnostics, or we want to have a way to work around them. Perhaps you’d
>> like to start a discussion around fixing that ?
>>
>> On 09 May 2016, at 08:06, Xiaodi Wu  wrote:
>>
>> I see your point that nothing breaks in the stdlib with your proposal
>> alone. It's undeniably true--by construction!--that a purely additive
>> feature, if never used, will not cause problems.
>>
>> That said, since the time that this feature was outlined in Doug's
>> manifesto, I have been wondering how clashes such as the examples in my
>> previous email are to be handled--i.e. what the rules of the language are
>> to be--which I think is certainly germane to your proposal. Can a
>> conforming type override a protocol typealias? Can a type conform to two
>> protocols with conflicting typealiases if all requirements are otherwise
>> satisfied? Surely, these merit discussion in your proposal.
>>
>> On Mon, May 9, 2016 at 12:48 AM David Hart  wrote:
>>
>>> Hello Xiaodi,
>>>
>>> What I mean by there is no impact on existing code is that the language
>>> change has no impact. Of course, if the Standard Library then declares a
>>> typealias Element in Sequence, it will clash with code which has declared
>>> an Element typealias in sub-protocols, but that is separate from the
>>> proposal.
>>>
>>> On 09 May 2016, at 07:28, Xiaodi Wu  wrote:
>>>
>>> If the protocol Sequence has typealias Element, does that mean I also
>>> have MyConformingSequence.Element?
>>>
>>> If so, I think there is a potential impact on existing code 

Re: [swift-evolution] Typealiases in protocols and protocol extensions

[Xiaodi Wu via swift-evolution]

On Mon, May 9, 2016 at 2:33 AM, David Hart  wrote:

>
> On 09 May 2016, at 09:30, Xiaodi Wu  wrote:
>
> Great, I hope this proposal finds much success with the community.
>
> One more thing: your title makes mention of protocol extensions, but
> protocol extensions are mentioned nowhere else. Please include details on
> typealiases in protocol extensions within the text or remove it altogether
> from the proposal.
>
>
> I left it in for now because it was explicitly mentioned in the Generics
> Manifesto (the title is a simple copy and paste), but I have yet to find
> good examples to illustrate their usefulness. Perhaps you could help me out
> on this one?
>

Nothing's coming to mind right off the bat. Perhaps the writer of the
Manifesto could chime in...

On Mon, May 9, 2016 at 02:24 David Hart  wrote:
>
>> On 09 May 2016, at 08:53, Xiaodi Wu  wrote:
>>
>> And to clarify, FWIW, I think it'd be wonderful to implement this
>> feature, and I share your sense that sometimes conversations on this list
>> get a little sidetracked. My comments are not meant to suggest that this is
>> not a good feature; rather, they go to your question to the list--does your
>> proposal need any modifications before a PR?
>>
>> IMO, some sections need to be fleshed out. Some discussion on how your
>> proposed rules interact with other aspects of the language when they are
>> used in the daily task of conforming types to protocols is called for. I
>> accept your point that perhaps it doesn't belong in the 'Impact on Existing
>> Code' section.
>>
>>
>> I’ll add something.
>>
>> I hope you'll forgive me for saying that the proposal seems, overall,
>> hastily written. That there are two misspelled instances of "typealias" in
>> a proposal about typealias does not give one confidence that what is
>> proposed has been sufficiently considered.
>>
>>
>> I don’t mind you saying it, it is a very early draft. That’s why I’m
>> putting it in front of the community before sending it for a Pull Request.
>>
>> On Mon, May 9, 2016 at 01:06 Xiaodi Wu  wrote:
>>
>>> I see your point that nothing breaks in the stdlib with your proposal
>>> alone. It's undeniably true--by construction!--that a purely additive
>>> feature, if never used, will not cause problems.
>>>
>>> That said, since the time that this feature was outlined in Doug's
>>> manifesto, I have been wondering how clashes such as the examples in my
>>> previous email are to be handled--i.e. what the rules of the language are
>>> to be--which I think is certainly germane to your proposal. Can a
>>> conforming type override a protocol typealias? Can a type conform to two
>>> protocols with conflicting typealiases if all requirements are otherwise
>>> satisfied? Surely, these merit discussion in your proposal.
>>>
>>> On Mon, May 9, 2016 at 12:48 AM David Hart  wrote:
>>>
 Hello Xiaodi,

 What I mean by there is no impact on existing code is that the language
 change has no impact. Of course, if the Standard Library then declares a
 typealias Element in Sequence, it will clash with code which has declared
 an Element typealias in sub-protocols, but that is separate from the
 proposal.

 On 09 May 2016, at 07:28, Xiaodi Wu  wrote:

 If the protocol Sequence has typealias Element, does that mean I also
 have MyConformingSequence.Element?

 If so, I think there is a potential impact on existing code not
 mentioned. Suppose MyConformingSequence already (unwisely) declares
 typealias Element. Now, what happens when I try to migrate my code to your
 proposed version of Swift?

 This is a toy example, of course. More generally, though, I wonder
 about this question:

 Suppose two protocols A and B each declare typealias Element. These
 typealiases are, as you proposed, intended to simplify referencing indirect
 associated types. But are they themselves considered protocol requirements?

 I ask because, suppose I want to conform type T to A and B. I implement
 all the required methods and properties for such conformance. I declare the
 appropriate typealiases for the associatedtypes declared in both protocols.
 But, if A.Element and B.Element are incompatible with each other, it is
 nonetheless impossible to conform T to both A and B? If it's forbidden,
 isn't that kind of a bummer, since what's getting in the way is a naming
 clash arising from a facility intended to simplify the naming of things
 rather than provide for new functionality? If it's permitted, what is
 T.Element? Some clarity here would be nice.
 On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution <
 swift-evolution@swift.org> wrote:

> Hello,
>
> I’ve come again with another proposal directly from the Generics
> 

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

[Xiaodi Wu via swift-evolution]

On Mon, May 9, 2016 at 2:47 AM, Patrick Smith  wrote:

> My point isn’t about what Swift 4 could be, but a timeline for something
> new to be made. Swift 3 is almost here. Personally I think Foundation,
> while venerable for its time, is a poor fit for the new world of Swift.
> Anyway, I’ll let the others speak as they had valid arguments.
>

I don't disagree with you that Foundation is venerable and a little out of
place. I just think some future replacement for Foundation is entirely
orthogonal to proposals about present-day improvements that improve it.

And please don't take my comments to be calling you out specifically; you
happened to be the most recent person to mention a future version of Swift,
but in earlier comments there are mentions of Swift 5 or Swift 6 being the
point at which language facilities will permit a pure Swift replacement for
Foundation. Let's say one of those Swift 6 features then slips to Swift 7,
after which we finally start work on NewFoundation, to be shipped with
Swift 8. Now the year is 2021 and we've already colonized Mars...

On 9 May 2016, at 3:40 PM, Xiaodi Wu  wrote:
>
> I'm +1 for this proposal. It is, IMO, a sensible way to evolve the current
> situation to provide for a nicer experience.
>
> As far as I can tell, arguments against the proposal argue for the
> elimination of Foundation and a totally new set of Swift-native facilities,
> which unless I'm mistaken is not at all on the roadmap. I just cannot agree
> that a superior alternative to this proposal is "wait for Swift 4." Why
> stop there? I hear Swift 9 is going to be pretty great...
> On Sun, May 8, 2016 at 11:24 PM Patrick Smith via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> But if the NS- prefix is removed now, then it will make it more painful
>> to have breaking changes down the road. I’d prefer to see breaking changes
>> happen and the introduction of new completely modern APIs. Even just
>> protocols that the NS- Foundation can implement.
>>
>> Say for example, a FileReferenceProtocol and a URLProtocol, where NSURL
>> could conform to both, but a modern implementation could have two separate
>> concrete struct types. Maybe that’s not feasible.
>>
>> It’s just a shame to say ‘goodbye Objective-C, hello Swift clean slate’,
>> and then bring Foundation along for the ride as a core part for writing new
>> modern applications.
>>
>> It would be great in my mind to have a plan to transition to a modern
>> ‘Foundation 2.0’. Say made using Swift 4.0 and its possible concurrency
>> operators. I think that would be the time to drop the NS- prefixes.
>>
>> On 9 May 2016, at 3:09 AM, Michael Sheaver via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Foundation is indeed tightly coupled with the Apple ecosystem; however
>> with the movement to open source, I think we are approaching a fork in the
>> road regarding this discussion. Like David articulated, Foundation either
>> will need to her decoupled from its Apple historical roots or a parallel
>> non-Apple Foundation will need to be developed. We all know how difficult
>> and painful it is to maintain two different code sets that do mostly the
>> same thing. My humble recommendation is that we start looking at decoupling
>> foundation from its roots and a good first step would be to remove the NS-
>> prefix. This change would do many positive things, including alerting
>> developers that change is coming.
>>
>> A long-term concern that I have is that if you do not begin the enormous
>> task of at least beginning to remove Apple-centric dependencies, then
>> sometime down the road someone outside the Apple environment will fork
>> Swift and take it in ways out of our control.
>>
>> In short, I am in favor of at least beginning the move toward removing
>> NS- from Foundation.
>>
>> On May 8, 2016, at 11:16 AM, Josh Parmenter via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> 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 <
>> swift-evolution@swift.org> >> wrote:
>>
>> It's not a goal to rewrite Foundation from scratch in Swift. All Swift
>> apps that are running out there today are in 

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Andrew Trick via swift-evolution]

> On May 7, 2016, at 11:51 PM, Dave Abrahams  wrote:
> 
>> Does Array have value semantics then only if T also has value
>> semantics?
> 
> This is a great question; I had to rewrite my response four times.
> 
> In my world, an Array always has value semantics if you respect the
> boundaries of element values as defined by ==.  That means that if T is
> a mutable reference type, you're not looking through references, because
> == is equivalent to ===.
> 
> Therefore, for almost any interesting SomeConstraint that doesn't refine
> ValueSemantics, then
> 
>  Array
> 
> only has value semantics if T has value semantics, since SomeConstraint
> presumably uses aspects of T other than reference identity.  

I just had a chance to digest Dave's answer. It explains a lot.

PureValue was defined in terms of the type's physical representation:
- A struct with no reference properties
- Recursively, a reference to immutable or uniquely referenced memory.

It's defined such that we can say Array is a PureValue iff T is a PureValue.

There is currently no procedure for determining PureValue because we have no 
way to declare that references are immutable or uniquely referenced. It would 
be a promise by the developer.

Now attempting to look at it from Dave's direction, value semantics apply to 
the variable's type, not the object's physical representation:

let v2 = v1
f(v1)
assert(v1 == v2)

If everything is a value, then this always works. Great!

If the variable's type does not allow mutating shared state, then operations on 
the variable are operating on a value.

protocol ValueP {
  func compute() -> Result // nonmutating
}

func g(v1 : ValueP) {
  let v2 = v1
  v1.compute()
  assert(v1 == v2)
}

Nice. ‘compute' cannot change the value. Those value semantics do not tell me 
anything about shared state or function purity. For that, I need some 
additional constraint on 'compute'. Knowing that it does not mutate the 'self' 
value is insufficient.

One way of doing that, for example, is to declare that 'compute' transitively 
cannot access globals *and* ValueP must be a PureValue. Now I can safely write 
this:

protocol ValueP : PureValue {
  @strawman_noglobal func compute() -> Result
}

/// Return (v1.compute, v2.compute)
func g(v1 : ValueP, v2 : ValueP) -> (Result, Result) {
  let r1 = v1.compute()
  if v1 == v2 {
return (r1, r1)
  }
  return (r1, v2.compute())
}

So, Dave is right that we need to decide soon whether we can make stronger 
assumptions about value semantics. But that is a separate question from how to 
express function purity. I don't think there is any urgency in introducing 
things like the PureValue protocol or @strawman_noglobals attribute, now that 
we have clearly established shared-state-mutability-by-default. When we want to 
seriously have that discussion, we should consider other alternatives. I would 
prefer to wait until indirect structs and improved CoW support have had more 
discussion.

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

Re: [swift-evolution] [Pitch] Require tuple conversions to be explicit when labels don't match

[Xiaodi Wu via swift-evolution]

Hmm, not as sure about that one. To my mind it's a clear expression of
intent there. You're saying you know what the labels are and you're
choosing not to repeat them. I think it should be on you if you express
that intent and you're just plain wrong.


On Mon, May 9, 2016 at 2:32 AM, Jacob Bandes-Storch 
wrote:

> ... and one might also want to require labels when passing values *to* a
> labeled tuple:
>
> func foo() -> (left: Int, right: Int) {
> return (3, 4)  // error: conversion between tuple types '(Int,
> Int)' and '(left: Int, right: Int)' requires explicit 'as' operator
> }
>
> I've personally been bitten by a typo of this sort (mistakenly swapping
> the values) before.
> Jacob
>
> On Mon, May 9, 2016 at 12:23 AM, Xiaodi Wu  wrote:
>
>> A sensible solution, IMO. Error with Fix-It when attempting to convert
>> implicitly between tuples with mismatched labels.
>>
>> On Mon, May 9, 2016 at 01:47 Jacob Bandes-Storch via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> There was some previous discussion under "[Discussion] Enforce argument
>>> labels on tuples
>>> ".
>>>
>>> Halfway through the thread, Haravikk clearly stated the key point:
>>>
>>> On Thu, Apr 21, 2016 at 12:14 AM, Haravikk via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 I think the important thing to remember is that the label check is
 intended to prevent cases like this:
 let a:(left:Int, right:Int) = (1, 2)
 var b:(right:Int, left:Int) = a
 While the two tuples are compatible by type, the meaning of the values
 may differ due to the different labels; in this case the values are
 represented in a different order that a developer should have to explicitly
 reverse to ensure they aren’t making a mistake, or they could represent
 radically different concepts altogether.
>>>
>>>
>>>
>>> I agree there's a potential for confusion here, and I suggest we should
>>> add an error (or warning) imploring the user to make the conversion
>>> explicit, when the source tuple is labeled:
>>>
>>> func foo() -> (left: Int, right: Int) { return (3, 4) }
>>>
>>> let (left: a, right: b) = foo()  // ok, labels match
>>>
>>> var x = 0, y = 0
>>> (left: x, right: y) = (1, 3)  // ok, source is unlabeled
>>>
>>> let (c, d) = foo()
>>> // error: conversion between tuple types '(left: Int, right: Int)'
>>> and '(Int, Int)' requires explicit 'as' operator
>>> // suggested fix: "let (c, d) = foo() as (Int, Int)"
>>>
>>> let (right: e, left: f) = foo()
>>> // error: conversion between tuple types '(left: Int, right: Int)'
>>> and '(right: Int, left: Int)' requires explicit 'as' operator
>>> // suggested fix: "let (right: e, left: f) = foo() as (right: Int,
>>> left: Int)"
>>>
>>>
>>> Thoughts?
>>>
>>> Jacob
>>> ___
>>> 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] Typealiases in protocols and protocol extensions

[David Hart via swift-evolution]

> On 09 May 2016, at 09:30, Xiaodi Wu  wrote:
> 
> Great, I hope this proposal finds much success with the community.
> 
> One more thing: your title makes mention of protocol extensions, but protocol 
> extensions are mentioned nowhere else. Please include details on typealiases 
> in protocol extensions within the text or remove it altogether from the 
> proposal.

I left it in for now because it was explicitly mentioned in the Generics 
Manifesto (the title is a simple copy and paste), but I have yet to find good 
examples to illustrate their usefulness. Perhaps you could help me out on this 
one?

> On Mon, May 9, 2016 at 02:24 David Hart  > wrote:
>> On 09 May 2016, at 08:53, Xiaodi Wu > > wrote:
>> 
>> And to clarify, FWIW, I think it'd be wonderful to implement this feature, 
>> and I share your sense that sometimes conversations on this list get a 
>> little sidetracked. My comments are not meant to suggest that this is not a 
>> good feature; rather, they go to your question to the list--does your 
>> proposal need any modifications before a PR?
>> 
>> IMO, some sections need to be fleshed out. Some discussion on how your 
>> proposed rules interact with other aspects of the language when they are 
>> used in the daily task of conforming types to protocols is called for. I 
>> accept your point that perhaps it doesn't belong in the 'Impact on Existing 
>> Code' section.
> 
> I’ll add something.
> 
>> I hope you'll forgive me for saying that the proposal seems, overall, 
>> hastily written. That there are two misspelled instances of "typealias" in a 
>> proposal about typealias does not give one confidence that what is proposed 
>> has been sufficiently considered.
> 
> I don’t mind you saying it, it is a very early draft. That’s why I’m putting 
> it in front of the community before sending it for a Pull Request.
> 
>> On Mon, May 9, 2016 at 01:06 Xiaodi Wu > > wrote:
>> I see your point that nothing breaks in the stdlib with your proposal alone. 
>> It's undeniably true--by construction!--that a purely additive feature, if 
>> never used, will not cause problems.
>> 
>> That said, since the time that this feature was outlined in Doug's 
>> manifesto, I have been wondering how clashes such as the examples in my 
>> previous email are to be handled--i.e. what the rules of the language are to 
>> be--which I think is certainly germane to your proposal. Can a conforming 
>> type override a protocol typealias? Can a type conform to two protocols with 
>> conflicting typealiases if all requirements are otherwise satisfied? Surely, 
>> these merit discussion in your proposal.
>> 
>> On Mon, May 9, 2016 at 12:48 AM David Hart > > wrote:
>> Hello Xiaodi,
>> 
>> What I mean by there is no impact on existing code is that the language 
>> change has no impact. Of course, if the Standard Library then declares a 
>> typealias Element in Sequence, it will clash with code which has declared an 
>> Element typealias in sub-protocols, but that is separate from the proposal.
>> 
>>> On 09 May 2016, at 07:28, Xiaodi Wu >> > wrote:
>>> 
>>> If the protocol Sequence has typealias Element, does that mean I also have 
>>> MyConformingSequence.Element?
>>> 
>>> If so, I think there is a potential impact on existing code not mentioned. 
>>> Suppose MyConformingSequence already (unwisely) declares typealias Element. 
>>> Now, what happens when I try to migrate my code to your proposed version of 
>>> Swift?
>>> 
>>> This is a toy example, of course. More generally, though, I wonder about 
>>> this question:
>>> 
>>> Suppose two protocols A and B each declare typealias Element. These 
>>> typealiases are, as you proposed, intended to simplify referencing indirect 
>>> associated types. But are they themselves considered protocol requirements?
>>> 
>>> I ask because, suppose I want to conform type T to A and B. I implement all 
>>> the required methods and properties for such conformance. I declare the 
>>> appropriate typealiases for the associatedtypes declared in both protocols. 
>>> But, if A.Element and B.Element are incompatible with each other, it is 
>>> nonetheless impossible to conform T to both A and B? If it's forbidden, 
>>> isn't that kind of a bummer, since what's getting in the way is a naming 
>>> clash arising from a facility intended to simplify the naming of things 
>>> rather than provide for new functionality? If it's permitted, what is 
>>> T.Element? Some clarity here would be nice.
>>> On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution 
>>> > wrote:
>>> Hello,
>>> 
>>> I’ve come again with another proposal directly from the Generics Manifesto. 
>>> Please let me 

Re: [swift-evolution] [Pitch] Require tuple conversions to be explicit when labels don't match

[Jacob Bandes-Storch via swift-evolution]

... and one might also want to require labels when passing values *to* a
labeled tuple:

func foo() -> (left: Int, right: Int) {
return (3, 4)  // error: conversion between tuple types '(Int,
Int)' and '(left: Int, right: Int)' requires explicit 'as' operator
}

I've personally been bitten by a typo of this sort (mistakenly swapping the
values) before.
Jacob

On Mon, May 9, 2016 at 12:23 AM, Xiaodi Wu  wrote:

> A sensible solution, IMO. Error with Fix-It when attempting to convert
> implicitly between tuples with mismatched labels.
>
> On Mon, May 9, 2016 at 01:47 Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> There was some previous discussion under "[Discussion] Enforce argument
>> labels on tuples
>> ".
>>
>> Halfway through the thread, Haravikk clearly stated the key point:
>>
>> On Thu, Apr 21, 2016 at 12:14 AM, Haravikk via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I think the important thing to remember is that the label check is
>>> intended to prevent cases like this:
>>> let a:(left:Int, right:Int) = (1, 2)
>>> var b:(right:Int, left:Int) = a
>>> While the two tuples are compatible by type, the meaning of the values
>>> may differ due to the different labels; in this case the values are
>>> represented in a different order that a developer should have to explicitly
>>> reverse to ensure they aren’t making a mistake, or they could represent
>>> radically different concepts altogether.
>>
>>
>>
>> I agree there's a potential for confusion here, and I suggest we should
>> add an error (or warning) imploring the user to make the conversion
>> explicit, when the source tuple is labeled:
>>
>> func foo() -> (left: Int, right: Int) { return (3, 4) }
>>
>> let (left: a, right: b) = foo()  // ok, labels match
>>
>> var x = 0, y = 0
>> (left: x, right: y) = (1, 3)  // ok, source is unlabeled
>>
>> let (c, d) = foo()
>> // error: conversion between tuple types '(left: Int, right: Int)'
>> and '(Int, Int)' requires explicit 'as' operator
>> // suggested fix: "let (c, d) = foo() as (Int, Int)"
>>
>> let (right: e, left: f) = foo()
>> // error: conversion between tuple types '(left: Int, right: Int)'
>> and '(right: Int, left: Int)' requires explicit 'as' operator
>> // suggested fix: "let (right: e, left: f) = foo() as (right: Int,
>> left: Int)"
>>
>>
>> Thoughts?
>>
>> Jacob
>> ___
>> 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] Typealiases in protocols and protocol extensions

[David Hart via swift-evolution]

> On 09 May 2016, at 09:16, Xiaodi Wu  wrote:
> 
> One more thought here:
> 
> It goes a long way to say "typealiases in protocols are to have the same 
> semantics as aliases outside protocols." I'm inclined to agree on that, but I 
> haven't thought it totally through.
> 
> Now, I can have private typealiases outside protocols. Could I have private 
> typealiases inside protocols? They'd be handy for referencing types while 
> implementing default methods in protocol extensions and whatnot without 
> worrying about collisions with typealiases in conforming types…

Sounds like it should be allowed. I’ll add something about it in the proposal. 
Could you give an example of what you mean by "without worrying about 
collisions with typealiases in conforming types…”?

> On Mon, May 9, 2016 at 01:52 David Hart  > wrote:
> I understand that name clashing in those instances is important to discuss, 
> but I still think it is slightly orthogonal to the proposal. Let me try to 
> explain why.
> 
> If typealises in protocols are to have the same semantics as alises outside 
> protocols (as I think they should), then they don’t change anything about the 
> rules of collision. For example, the problem already exists today with 
> associated types:
> 
> protocol Foo {
> associatedtype Inner: IntegerType
> func foo(inner: Inner)
> }
> 
> protocol Bar {
> associatedtype Inner: FloatingPointType
> var inner: Inner { get }
> }
> 
> struct FooBarImpl: Foo, Bar { // error: Type ‘FooBarImpl’ does not conform to 
> protocol ‘Bar'
> func foo(inner: Int) {}
> var inner: Float
> }
> 
> Type aliasing would not change anything about the fact that those collisions 
> already exists in the language and are not very well handled: either they are 
> meant to be forbidden but in that case we need better diagnostics, or we want 
> to have a way to work around them. Perhaps you’d like to start a discussion 
> around fixing that ?
> 
>> On 09 May 2016, at 08:06, Xiaodi Wu > > wrote:
>> 
>> I see your point that nothing breaks in the stdlib with your proposal alone. 
>> It's undeniably true--by construction!--that a purely additive feature, if 
>> never used, will not cause problems.
>> 
>> That said, since the time that this feature was outlined in Doug's 
>> manifesto, I have been wondering how clashes such as the examples in my 
>> previous email are to be handled--i.e. what the rules of the language are to 
>> be--which I think is certainly germane to your proposal. Can a conforming 
>> type override a protocol typealias? Can a type conform to two protocols with 
>> conflicting typealiases if all requirements are otherwise satisfied? Surely, 
>> these merit discussion in your proposal.
>> 
>> On Mon, May 9, 2016 at 12:48 AM David Hart > > wrote:
>> Hello Xiaodi,
>> 
>> What I mean by there is no impact on existing code is that the language 
>> change has no impact. Of course, if the Standard Library then declares a 
>> typealias Element in Sequence, it will clash with code which has declared an 
>> Element typealias in sub-protocols, but that is separate from the proposal.
>> 
>>> On 09 May 2016, at 07:28, Xiaodi Wu >> > wrote:
>>> 
>>> If the protocol Sequence has typealias Element, does that mean I also have 
>>> MyConformingSequence.Element?
>>> 
>>> If so, I think there is a potential impact on existing code not mentioned. 
>>> Suppose MyConformingSequence already (unwisely) declares typealias Element. 
>>> Now, what happens when I try to migrate my code to your proposed version of 
>>> Swift?
>>> 
>>> This is a toy example, of course. More generally, though, I wonder about 
>>> this question:
>>> 
>>> Suppose two protocols A and B each declare typealias Element. These 
>>> typealiases are, as you proposed, intended to simplify referencing indirect 
>>> associated types. But are they themselves considered protocol requirements?
>>> 
>>> I ask because, suppose I want to conform type T to A and B. I implement all 
>>> the required methods and properties for such conformance. I declare the 
>>> appropriate typealiases for the associatedtypes declared in both protocols. 
>>> But, if A.Element and B.Element are incompatible with each other, it is 
>>> nonetheless impossible to conform T to both A and B? If it's forbidden, 
>>> isn't that kind of a bummer, since what's getting in the way is a naming 
>>> clash arising from a facility intended to simplify the naming of things 
>>> rather than provide for new functionality? If it's permitted, what is 
>>> T.Element? Some clarity here would be nice.
>>> On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution 
>>> > wrote:
>>> Hello,
>>> 
>>> I’ve come again with another proposal 

Re: [swift-evolution] Typealiases in protocols and protocol extensions

[David Hart via swift-evolution]

> On 09 May 2016, at 08:53, Xiaodi Wu  wrote:
> 
> And to clarify, FWIW, I think it'd be wonderful to implement this feature, 
> and I share your sense that sometimes conversations on this list get a little 
> sidetracked. My comments are not meant to suggest that this is not a good 
> feature; rather, they go to your question to the list--does your proposal 
> need any modifications before a PR?
> 
> IMO, some sections need to be fleshed out. Some discussion on how your 
> proposed rules interact with other aspects of the language when they are used 
> in the daily task of conforming types to protocols is called for. I accept 
> your point that perhaps it doesn't belong in the 'Impact on Existing Code' 
> section.

I’ll add something.

> I hope you'll forgive me for saying that the proposal seems, overall, hastily 
> written. That there are two misspelled instances of "typealias" in a proposal 
> about typealias does not give one confidence that what is proposed has been 
> sufficiently considered.

I don’t mind you saying it, it is a very early draft. That’s why I’m putting it 
in front of the community before sending it for a Pull Request.

> On Mon, May 9, 2016 at 01:06 Xiaodi Wu  > wrote:
> I see your point that nothing breaks in the stdlib with your proposal alone. 
> It's undeniably true--by construction!--that a purely additive feature, if 
> never used, will not cause problems.
> 
> That said, since the time that this feature was outlined in Doug's manifesto, 
> I have been wondering how clashes such as the examples in my previous email 
> are to be handled--i.e. what the rules of the language are to be--which I 
> think is certainly germane to your proposal. Can a conforming type override a 
> protocol typealias? Can a type conform to two protocols with conflicting 
> typealiases if all requirements are otherwise satisfied? Surely, these merit 
> discussion in your proposal.
> 
> On Mon, May 9, 2016 at 12:48 AM David Hart  > wrote:
> Hello Xiaodi,
> 
> What I mean by there is no impact on existing code is that the language 
> change has no impact. Of course, if the Standard Library then declares a 
> typealias Element in Sequence, it will clash with code which has declared an 
> Element typealias in sub-protocols, but that is separate from the proposal.
> 
>> On 09 May 2016, at 07:28, Xiaodi Wu > > wrote:
>> 
>> If the protocol Sequence has typealias Element, does that mean I also have 
>> MyConformingSequence.Element?
>> 
>> If so, I think there is a potential impact on existing code not mentioned. 
>> Suppose MyConformingSequence already (unwisely) declares typealias Element. 
>> Now, what happens when I try to migrate my code to your proposed version of 
>> Swift?
>> 
>> This is a toy example, of course. More generally, though, I wonder about 
>> this question:
>> 
>> Suppose two protocols A and B each declare typealias Element. These 
>> typealiases are, as you proposed, intended to simplify referencing indirect 
>> associated types. But are they themselves considered protocol requirements?
>> 
>> I ask because, suppose I want to conform type T to A and B. I implement all 
>> the required methods and properties for such conformance. I declare the 
>> appropriate typealiases for the associatedtypes declared in both protocols. 
>> But, if A.Element and B.Element are incompatible with each other, it is 
>> nonetheless impossible to conform T to both A and B? If it's forbidden, 
>> isn't that kind of a bummer, since what's getting in the way is a naming 
>> clash arising from a facility intended to simplify the naming of things 
>> rather than provide for new functionality? If it's permitted, what is 
>> T.Element? Some clarity here would be nice.
>> On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution 
>> > wrote:
>> Hello,
>> 
>> I’ve come again with another proposal directly from the Generics Manifesto. 
>> Please let me know if it needs any modifications before sending the pull 
>> request.
>> 
>> Typealiases in protocols and protocol extensions
>> 
>> Proposal: SE- 
>> 
>> Authors: David Hart , Doug Gregor 
>> 
>> Status: TBD
>> Review manager: TBD
>>  
>> Introduction
>> 
>> This proposal is from the Generics Manifesto 
>>  and 
>> brings the typealias keyword back into protocols for type aliasing.
>> 
>>  
>> 

Re: [swift-evolution] multi-line string literals.

[Vladimir.S via swift-evolution]

Btw, in c# we have @ to drop escapes:
@"c:\Docs\Source\a.txt"  // rather than "c:\\Docs\\Source\\a.txt"
@"""Ahoy!"" cried the captain." // "Ahoy!" cried the captain.

and(!) also as 'marker' that allows to use keywords as identifiers:
class @class
{
   public static void @static(bool @bool) {..}
..
}

so, probably it is OK to have backtick also as 'special' string marker in 
Swift ?

`abc "def" \(hahaha /// \total-10`

Also, wanted to drop some alternatives:
* what  about single quote? like
'abc "def" \(hahaha /// \total-10'
(if single quote appear in text - it should be doubled, so
'example '' - is a "single" quote'

* what about @ like in c# for string literals just to say "do not process 
escapes" (double quotes should be doubled) :

@"this just text \( \t \n but with ""double quotes"""

* what about $".."$ to mark a sting as-is, without escapes, without 
interpolation, allows double quote without escaping(putting twice)? Yes, "$ 
combination will not be allowed inside of such string.



On 09.05.2016 1:13, Brent Royal-Gordon via swift-evolution wrote:

By the way has the backtick or triple backtick been considered?


Backticks already have a meaning—they "quote" an identifier which would
otherwise be taken as a keyword.

--
Brent Royal-Gordon
Sent from my iPhone

On May 8, 2016, at 2:58 PM, Ricardo Parada > wrote:


The _" and "_  are a good alternative I think.

For some reason the underscore bothers me: it doesn't look as good
aesthetically as others, and because it is already used for a couple of
other things in Swift (to make large numbers readable and as a
placeholder to discard a value).






On May 7, 2016, at 7:24 PM, L. Mihalkovic > wrote:



Regards
(From mobile)


On May 8, 2016, at 12:49 AM, Ricardo Parada via swift-evolution
> wrote:



It seems to me like this would take care of what is needed 99% of the
time.

I've seen many who don't favor continuation quotes.

The other option could be triple quote """ and make the continuation
quote optional. Not using the continuation quote would require the
closing triple quote """


For having built a prototype, I've come to realize that there are more
alternatives.

This is some of my own tests:
https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c

The idea of these M/e or any other similar prefix remind me of my perl
days (there were a lot of these), and IMO have little to do with the
rest of Swift.


On May 7, 2016, at 9:48 AM, Brent Royal-Gordon via swift-evolution
> wrote:

```
// Something like:
let xml = M"
   "
   "
   "\(author)
   "
   "
```

___
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] [Pitch] Require tuple conversions to be explicit when labels don't match

[Xiaodi Wu via swift-evolution]

A sensible solution, IMO. Error with Fix-It when attempting to convert
implicitly between tuples with mismatched labels.

On Mon, May 9, 2016 at 01:47 Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> There was some previous discussion under "[Discussion] Enforce argument
> labels on tuples
> ".
>
> Halfway through the thread, Haravikk clearly stated the key point:
>
> On Thu, Apr 21, 2016 at 12:14 AM, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I think the important thing to remember is that the label check is
>> intended to prevent cases like this:
>> let a:(left:Int, right:Int) = (1, 2)
>> var b:(right:Int, left:Int) = a
>> While the two tuples are compatible by type, the meaning of the values
>> may differ due to the different labels; in this case the values are
>> represented in a different order that a developer should have to explicitly
>> reverse to ensure they aren’t making a mistake, or they could represent
>> radically different concepts altogether.
>
>
>
> I agree there's a potential for confusion here, and I suggest we should
> add an error (or warning) imploring the user to make the conversion
> explicit, when the source tuple is labeled:
>
> func foo() -> (left: Int, right: Int) { return (3, 4) }
>
> let (left: a, right: b) = foo()  // ok, labels match
>
> var x = 0, y = 0
> (left: x, right: y) = (1, 3)  // ok, source is unlabeled
>
> let (c, d) = foo()
> // error: conversion between tuple types '(left: Int, right: Int)' and
> '(Int, Int)' requires explicit 'as' operator
> // suggested fix: "let (c, d) = foo() as (Int, Int)"
>
> let (right: e, left: f) = foo()
> // error: conversion between tuple types '(left: Int, right: Int)' and
> '(right: Int, left: Int)' requires explicit 'as' operator
> // suggested fix: "let (right: e, left: f) = foo() as (right: Int,
> left: Int)"
>
>
> Thoughts?
>
> Jacob
> ___
> 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] Typealiases in protocols and protocol extensions

[Xiaodi Wu via swift-evolution]

One more thought here:

It goes a long way to say "typealiases in protocols are to have the same
semantics as aliases outside protocols." I'm inclined to agree on that, but
I haven't thought it totally through.

Now, I can have private typealiases outside protocols. Could I have private
typealiases inside protocols? They'd be handy for referencing types while
implementing default methods in protocol extensions and whatnot without
worrying about collisions with typealiases in conforming types...

On Mon, May 9, 2016 at 01:52 David Hart  wrote:

> I understand that name clashing in those instances is important to
> discuss, but I still think it is slightly orthogonal to the proposal. Let
> me try to explain why.
>
> If typealises in protocols are to have the same semantics as alises
> outside protocols (as I think they should), then they don’t change anything
> about the rules of collision. For example, the problem already exists today
> with associated types:
>
> protocol Foo {
> associatedtype Inner: IntegerType
> func foo(inner: Inner)
> }
>
> protocol Bar {
> associatedtype Inner: FloatingPointType
> var inner: Inner { get }
> }
>
> struct FooBarImpl: Foo, Bar { // error: Type ‘FooBarImpl’ does not conform
> to protocol ‘Bar'
> func foo(inner: Int) {}
> var inner: Float
> }
>
> Type aliasing would not change anything about the fact that those
> collisions already exists in the language and are not very well handled:
> either they are meant to be forbidden but in that case we need better
> diagnostics, or we want to have a way to work around them. Perhaps you’d
> like to start a discussion around fixing that ?
>
> On 09 May 2016, at 08:06, Xiaodi Wu  wrote:
>
> I see your point that nothing breaks in the stdlib with your proposal
> alone. It's undeniably true--by construction!--that a purely additive
> feature, if never used, will not cause problems.
>
> That said, since the time that this feature was outlined in Doug's
> manifesto, I have been wondering how clashes such as the examples in my
> previous email are to be handled--i.e. what the rules of the language are
> to be--which I think is certainly germane to your proposal. Can a
> conforming type override a protocol typealias? Can a type conform to two
> protocols with conflicting typealiases if all requirements are otherwise
> satisfied? Surely, these merit discussion in your proposal.
>
> On Mon, May 9, 2016 at 12:48 AM David Hart  wrote:
>
>> Hello Xiaodi,
>>
>> What I mean by there is no impact on existing code is that the language
>> change has no impact. Of course, if the Standard Library then declares a
>> typealias Element in Sequence, it will clash with code which has declared
>> an Element typealias in sub-protocols, but that is separate from the
>> proposal.
>>
>> On 09 May 2016, at 07:28, Xiaodi Wu  wrote:
>>
>> If the protocol Sequence has typealias Element, does that mean I also
>> have MyConformingSequence.Element?
>>
>> If so, I think there is a potential impact on existing code not
>> mentioned. Suppose MyConformingSequence already (unwisely) declares
>> typealias Element. Now, what happens when I try to migrate my code to your
>> proposed version of Swift?
>>
>> This is a toy example, of course. More generally, though, I wonder about
>> this question:
>>
>> Suppose two protocols A and B each declare typealias Element. These
>> typealiases are, as you proposed, intended to simplify referencing indirect
>> associated types. But are they themselves considered protocol requirements?
>>
>> I ask because, suppose I want to conform type T to A and B. I implement
>> all the required methods and properties for such conformance. I declare the
>> appropriate typealiases for the associatedtypes declared in both protocols.
>> But, if A.Element and B.Element are incompatible with each other, it is
>> nonetheless impossible to conform T to both A and B? If it's forbidden,
>> isn't that kind of a bummer, since what's getting in the way is a naming
>> clash arising from a facility intended to simplify the naming of things
>> rather than provide for new functionality? If it's permitted, what is
>> T.Element? Some clarity here would be nice.
>> On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hello,
>>>
>>> I’ve come again with another proposal directly from the Generics
>>> Manifesto. Please let me know if it needs any modifications before sending
>>> the pull request.
>>>
>>> Typealiases in protocols and protocol extensions
>>>
>>>- Proposal: SE-
>>>
>>> 
>>>- Authors: David Hart , Doug Gregor
>>>
>>>- Status: TBD
>>>- Review manager: TBD
>>>
>>>
>>> 

Re: [swift-evolution] Typealiases in protocols and protocol extensions

[Xiaodi Wu via swift-evolution]

I agree with you that similar issues exist with the status quo. I'm not
asking that you fix them with your proposal, just that you document how
your proposed feature will work--i.e. please include some of this stuff you
just wrote here somewhere in the proposal text.

Your question to the list solicited suggestions for modifications to your
proposal. Mine is to flesh out "proposed solution" and/or "detailed
design." In "proposed solution," you describe how what you're proposing
would be useful based on a lone example. Elsewhere, under "motivation" you
write that you're proposing "true associated type aliases"--what, exactly,
is that? how does it interact with type aliases in conforming types and in
sub-protocols? can they be overridden? can they be masked like non-default
methods in protocol extensions are currently? I don't really have a beef
with the proposal whether the answers are yes or no, but I'd like to know
what the answers are by reading the proposal.

On Mon, May 9, 2016 at 01:52 David Hart  wrote:

> I understand that name clashing in those instances is important to
> discuss, but I still think it is slightly orthogonal to the proposal. Let
> me try to explain why.
>
> If typealises in protocols are to have the same semantics as alises
> outside protocols (as I think they should), then they don’t change anything
> about the rules of collision. For example, the problem already exists today
> with associated types:
>
> protocol Foo {
> associatedtype Inner: IntegerType
> func foo(inner: Inner)
> }
>
> protocol Bar {
> associatedtype Inner: FloatingPointType
> var inner: Inner { get }
> }
>
> struct FooBarImpl: Foo, Bar { // error: Type ‘FooBarImpl’ does not conform
> to protocol ‘Bar'
> func foo(inner: Int) {}
> var inner: Float
> }
>
> Type aliasing would not change anything about the fact that those
> collisions already exists in the language and are not very well handled:
> either they are meant to be forbidden but in that case we need better
> diagnostics, or we want to have a way to work around them. Perhaps you’d
> like to start a discussion around fixing that ?
>
> On 09 May 2016, at 08:06, Xiaodi Wu  wrote:
>
> I see your point that nothing breaks in the stdlib with your proposal
> alone. It's undeniably true--by construction!--that a purely additive
> feature, if never used, will not cause problems.
>
> That said, since the time that this feature was outlined in Doug's
> manifesto, I have been wondering how clashes such as the examples in my
> previous email are to be handled--i.e. what the rules of the language are
> to be--which I think is certainly germane to your proposal. Can a
> conforming type override a protocol typealias? Can a type conform to two
> protocols with conflicting typealiases if all requirements are otherwise
> satisfied? Surely, these merit discussion in your proposal.
>
> On Mon, May 9, 2016 at 12:48 AM David Hart  wrote:
>
>> Hello Xiaodi,
>>
>> What I mean by there is no impact on existing code is that the language
>> change has no impact. Of course, if the Standard Library then declares a
>> typealias Element in Sequence, it will clash with code which has declared
>> an Element typealias in sub-protocols, but that is separate from the
>> proposal.
>>
>> On 09 May 2016, at 07:28, Xiaodi Wu  wrote:
>>
>> If the protocol Sequence has typealias Element, does that mean I also
>> have MyConformingSequence.Element?
>>
>> If so, I think there is a potential impact on existing code not
>> mentioned. Suppose MyConformingSequence already (unwisely) declares
>> typealias Element. Now, what happens when I try to migrate my code to your
>> proposed version of Swift?
>>
>> This is a toy example, of course. More generally, though, I wonder about
>> this question:
>>
>> Suppose two protocols A and B each declare typealias Element. These
>> typealiases are, as you proposed, intended to simplify referencing indirect
>> associated types. But are they themselves considered protocol requirements?
>>
>> I ask because, suppose I want to conform type T to A and B. I implement
>> all the required methods and properties for such conformance. I declare the
>> appropriate typealiases for the associatedtypes declared in both protocols.
>> But, if A.Element and B.Element are incompatible with each other, it is
>> nonetheless impossible to conform T to both A and B? If it's forbidden,
>> isn't that kind of a bummer, since what's getting in the way is a naming
>> clash arising from a facility intended to simplify the naming of things
>> rather than provide for new functionality? If it's permitted, what is
>> T.Element? Some clarity here would be nice.
>> On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hello,
>>>
>>> I’ve come again with another proposal directly from the Generics
>>> Manifesto. Please let me know if it needs any 

Re: [swift-evolution] Typealiases in protocols and protocol extensions

[Xiaodi Wu via swift-evolution]

And to clarify, FWIW, I think it'd be wonderful to implement this feature,
and I share your sense that sometimes conversations on this list get a
little sidetracked. My comments are not meant to suggest that this is not a
good feature; rather, they go to your question to the list--does your
proposal need any modifications before a PR?

IMO, some sections need to be fleshed out. Some discussion on how your
proposed rules interact with other aspects of the language when they are
used in the daily task of conforming types to protocols is called for. I
accept your point that perhaps it doesn't belong in the 'Impact on Existing
Code' section.

I hope you'll forgive me for saying that the proposal seems, overall,
hastily written. That there are two misspelled instances of "typealias" in
a proposal about typealias does not give one confidence that what is
proposed has been sufficiently considered.

On Mon, May 9, 2016 at 01:06 Xiaodi Wu  wrote:

> I see your point that nothing breaks in the stdlib with your proposal
> alone. It's undeniably true--by construction!--that a purely additive
> feature, if never used, will not cause problems.
>
> That said, since the time that this feature was outlined in Doug's
> manifesto, I have been wondering how clashes such as the examples in my
> previous email are to be handled--i.e. what the rules of the language are
> to be--which I think is certainly germane to your proposal. Can a
> conforming type override a protocol typealias? Can a type conform to two
> protocols with conflicting typealiases if all requirements are otherwise
> satisfied? Surely, these merit discussion in your proposal.
>
> On Mon, May 9, 2016 at 12:48 AM David Hart  wrote:
>
>> Hello Xiaodi,
>>
>> What I mean by there is no impact on existing code is that the language
>> change has no impact. Of course, if the Standard Library then declares a
>> typealias Element in Sequence, it will clash with code which has declared
>> an Element typealias in sub-protocols, but that is separate from the
>> proposal.
>>
>> On 09 May 2016, at 07:28, Xiaodi Wu  wrote:
>>
>> If the protocol Sequence has typealias Element, does that mean I also
>> have MyConformingSequence.Element?
>>
>> If so, I think there is a potential impact on existing code not
>> mentioned. Suppose MyConformingSequence already (unwisely) declares
>> typealias Element. Now, what happens when I try to migrate my code to your
>> proposed version of Swift?
>>
>> This is a toy example, of course. More generally, though, I wonder about
>> this question:
>>
>> Suppose two protocols A and B each declare typealias Element. These
>> typealiases are, as you proposed, intended to simplify referencing indirect
>> associated types. But are they themselves considered protocol requirements?
>>
>> I ask because, suppose I want to conform type T to A and B. I implement
>> all the required methods and properties for such conformance. I declare the
>> appropriate typealiases for the associatedtypes declared in both protocols.
>> But, if A.Element and B.Element are incompatible with each other, it is
>> nonetheless impossible to conform T to both A and B? If it's forbidden,
>> isn't that kind of a bummer, since what's getting in the way is a naming
>> clash arising from a facility intended to simplify the naming of things
>> rather than provide for new functionality? If it's permitted, what is
>> T.Element? Some clarity here would be nice.
>> On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hello,
>>>
>>> I’ve come again with another proposal directly from the Generics
>>> Manifesto. Please let me know if it needs any modifications before sending
>>> the pull request.
>>>
>>> Typealiases in protocols and protocol extensions
>>>
>>>- Proposal: SE-
>>>
>>> 
>>>- Authors: David Hart , Doug Gregor
>>>
>>>- Status: TBD
>>>- Review manager: TBD
>>>
>>>
>>> 
>>> Introduction
>>>
>>> This proposal is from the Generics Manifesto
>>>  and
>>> brings the typealias keyword back into protocols for type aliasing.
>>>
>>> 
>>> Motivation
>>>
>>> In Swift versions prior to 2.2, the typelias keyword was used outside
>>> of protocols to declare type aliases and in protocols to declare associated
>>> types. Since SE-0011
>>> 
>>>  and
>>> Swift 2.2, 

[swift-evolution] [Pitch] Require tuple conversions to be explicit when labels don't match

[Jacob Bandes-Storch via swift-evolution]

There was some previous discussion under "[Discussion] Enforce argument
labels on tuples
".

Halfway through the thread, Haravikk clearly stated the key point:

On Thu, Apr 21, 2016 at 12:14 AM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> I think the important thing to remember is that the label check is
> intended to prevent cases like this:
> let a:(left:Int, right:Int) = (1, 2)
> var b:(right:Int, left:Int) = a
> While the two tuples are compatible by type, the meaning of the values
> may differ due to the different labels; in this case the values are
> represented in a different order that a developer should have to explicitly
> reverse to ensure they aren’t making a mistake, or they could represent
> radically different concepts altogether.



I agree there's a potential for confusion here, and I suggest we should add
an error (or warning) imploring the user to make the conversion explicit,
when the source tuple is labeled:

func foo() -> (left: Int, right: Int) { return (3, 4) }

let (left: a, right: b) = foo()  // ok, labels match

var x = 0, y = 0
(left: x, right: y) = (1, 3)  // ok, source is unlabeled

let (c, d) = foo()
// error: conversion between tuple types '(left: Int, right: Int)' and
'(Int, Int)' requires explicit 'as' operator
// suggested fix: "let (c, d) = foo() as (Int, Int)"

let (right: e, left: f) = foo()
// error: conversion between tuple types '(left: Int, right: Int)' and
'(right: Int, left: Int)' requires explicit 'as' operator
// suggested fix: "let (right: e, left: f) = foo() as (right: Int,
left: Int)"


Thoughts?

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

Re: [swift-evolution] Typealiases in protocols and protocol extensions

[Xiaodi Wu via swift-evolution]

I see your point that nothing breaks in the stdlib with your proposal
alone. It's undeniably true--by construction!--that a purely additive
feature, if never used, will not cause problems.

That said, since the time that this feature was outlined in Doug's
manifesto, I have been wondering how clashes such as the examples in my
previous email are to be handled--i.e. what the rules of the language are
to be--which I think is certainly germane to your proposal. Can a
conforming type override a protocol typealias? Can a type conform to two
protocols with conflicting typealiases if all requirements are otherwise
satisfied? Surely, these merit discussion in your proposal.

On Mon, May 9, 2016 at 12:48 AM David Hart  wrote:

> Hello Xiaodi,
>
> What I mean by there is no impact on existing code is that the language
> change has no impact. Of course, if the Standard Library then declares a
> typealias Element in Sequence, it will clash with code which has declared
> an Element typealias in sub-protocols, but that is separate from the
> proposal.
>
> On 09 May 2016, at 07:28, Xiaodi Wu  wrote:
>
> If the protocol Sequence has typealias Element, does that mean I also have
> MyConformingSequence.Element?
>
> If so, I think there is a potential impact on existing code not mentioned.
> Suppose MyConformingSequence already (unwisely) declares typealias Element.
> Now, what happens when I try to migrate my code to your proposed version of
> Swift?
>
> This is a toy example, of course. More generally, though, I wonder about
> this question:
>
> Suppose two protocols A and B each declare typealias Element. These
> typealiases are, as you proposed, intended to simplify referencing indirect
> associated types. But are they themselves considered protocol requirements?
>
> I ask because, suppose I want to conform type T to A and B. I implement
> all the required methods and properties for such conformance. I declare the
> appropriate typealiases for the associatedtypes declared in both protocols.
> But, if A.Element and B.Element are incompatible with each other, it is
> nonetheless impossible to conform T to both A and B? If it's forbidden,
> isn't that kind of a bummer, since what's getting in the way is a naming
> clash arising from a facility intended to simplify the naming of things
> rather than provide for new functionality? If it's permitted, what is
> T.Element? Some clarity here would be nice.
> On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello,
>>
>> I’ve come again with another proposal directly from the Generics
>> Manifesto. Please let me know if it needs any modifications before sending
>> the pull request.
>>
>> Typealiases in protocols and protocol extensions
>>
>>- Proposal: SE-
>>
>> 
>>- Authors: David Hart , Doug Gregor
>>
>>- Status: TBD
>>- Review manager: TBD
>>
>>
>> 
>> Introduction
>>
>> This proposal is from the Generics Manifesto
>>  and
>> brings the typealias keyword back into protocols for type aliasing.
>>
>> 
>> Motivation
>>
>> In Swift versions prior to 2.2, the typelias keyword was used outside of
>> protocols to declare type aliases and in protocols to declare associated
>> types. Since SE-0011
>> 
>>  and
>> Swift 2.2, associated type now use the associatedtype keyword and
>> typelias is available for implementing true associated type aliases.
>>
>> Proposed
>> solution
>>
>> The solution allows the creation of associated type aliases. Here is an
>> example from the standard library:
>>
>> protocol Sequence {
>>   associatedtype Iterator : IteratorProtocol
>>   typealias Element = Iterator.Element
>> }
>>
>> The example above shows how this simplifies referencing indirect
>> associated types:
>>
>> func sum(sequence: T) -> Int {
>> return sequence.reduce(0, combine: +)
>> }
>>
>>
>> Detailed
>> design
>>
>> The following grammar rules needs to be added:
>>
>> *protocol-member-declaration* → *protocol-typealias-declaration*
>>
>> *protocol-typealias-declaration* → *typealias-declaration*
>>
>>