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, associated type now use the associatedtype keyword and
>>> typ

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

[David Hart via swift-evolution]

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 
>> mailto: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

[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*
>>
>> 

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

[David Hart via swift-evolution]

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 
> mailto: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
> 
>  
> Impact
>  on existing code
> 
> This will have no impact on existing code, but will probably require 
> improving the Fix-It that was created for migrating typealias to 
> associatedtype in Swift 2.2.
> ___
> 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

[Xiaodi Wu via swift-evolution]

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 fact using a combination of
> Swift, Objective-C, C, C++, various flavors of assembly, and more. The goal
> is to present the existing API of Foundation in a way that fits in with the
> language today while allowing us to iteratively improve it over time.
>
> Perhaps my concern is a higher level - I don't understand where Foundation
> is envisioned going.
>
> From my perspective, Foundation is highly coupled to Apple platforms and
> Objective-C on one side, and part of the Swift standard library on the
> other. Perhaps long-term Foundation should be split into two new things - a
> core library for cross-platform swift development, and the infrastructure
> for Objective-C interoperability on apple platforms only.
>
> -DW
> ___
> swift-evolution mailing list
> swift-evolution@swift.org >
> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> 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

[Morten Bek Ditlevsen via swift-evolution]

This would be an excellent solution to the issue.
Do you know if there are any existing plans for something like the
DecimalLiteralConvertible?

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.


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 <
> swift-evolution@swift.org> wrote:
> >>
> >>>
> >>> On May 6, 2016, at 2:24 AM, Morten Bek Ditlevsen via swift-evolution <
> swift-evolution@swift.org> 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`.
> >>  init(decimalSignificand: Component, decimalExponent: Component)
> >> }
> >>
> >> // A type that can be initialized from a hexadecimal floating point
> >> // literal, such as `0x1.8p-2`.
> >> protocol HexFloatLiteralConvertible {
> >>  // The integer type used to represent the significand and exponent of
> the value.
> >>  typealias Component: IntegerLiteralConvertible
> >>
> >>  // Construct a value equal to `hexadecimalSignificand *
> 2**binaryExponent`.
> >>  init(hexadecimalSignificand: Component, bina

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

[Xiaodi Wu via swift-evolution]

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*
>
> Impact
> on existing code
> This will have no impact on existing code, but will probably require
> improving the Fix-It that was created for migrating typealias to
> associatedtype in Swift 2.2.
> ___
> 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

[Patrick Smith via swift-evolution]

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 
>  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 
>> mailto: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 
>> > > >> wrote:
>> 
>> It's not a goal to rewrite Foundation from scratch in Swift. All Swift apps 
>> that are running out there today are in fact using a combination of Swift, 
>> Objective-C, C, C++, various flavors of assembly, and more. The goal is to 
>> present the existing API of Foundation in a way that fits in with the 
>> language today while allowing us to iteratively improve it over time.
>> 
>> Perhaps my concern is a higher level - I don't understand where Foundation 
>> is envisioned going.
>> 
>> From my perspective, Foundation is highly coupled to Apple platforms and 
>> Objective-C on one side, and part of the Swift standard library on the 
>> other. Perhaps long-term Foundation should be split into two new things - a 
>> core library for cross-platform swift development, and the infrastructure 
>> for Objective-C interoperability on apple platforms only.
>> 
>> -DW
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> > >
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> 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] Typealiases in protocols and protocol extensions

[David Hart via swift-evolution]

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

 
Impact
 on existing code

This will have no impact on existing code, but will probably require improving 
the Fix-It that was created for migrating typealias to associatedtype in Swift 
2.2.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Manifesto] Completing Generics

[Austin Zheng via swift-evolution]

That seems reasonable. Onward ho!

On Sun, May 8, 2016 at 3:46 PM, David Hart  wrote:

>
> On 09 May 2016, at 00:38, Austin Zheng  wrote:
>
> Is the plan to eventually support "multiple" forms of concrete same-type
> requirement syntax - the existing "where Element == SomeConcreteType" and
> the generic parameterized extensions described elsewhere? If not, the
> syntax should probably be discussed as part of a pre-proposal thread before
> anything else happens.
>
>
> The way modifications have gone through swift-evolution, it seems like it
> would be more logical to implement it with no syntax change first and only
> then propose and discuss generic parameterised extensions.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Manifesto] Completing Generics

[David Hart via swift-evolution]

> On 09 May 2016, at 00:38, Austin Zheng  wrote:
> 
> Is the plan to eventually support "multiple" forms of concrete same-type 
> requirement syntax - the existing "where Element == SomeConcreteType" and the 
> generic parameterized extensions described elsewhere? If not, the syntax 
> should probably be discussed as part of a pre-proposal thread before anything 
> else happens.

The way modifications have gone through swift-evolution, it seems like it would 
be more logical to implement it with no syntax change first and only then 
propose and discuss generic parameterised extensions.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Manifesto] Completing Generics

[Austin Zheng via swift-evolution]

Is the plan to eventually support "multiple" forms of concrete same-type
requirement syntax - the existing "where Element == SomeConcreteType" and
the generic parameterized extensions described elsewhere? If not, the
syntax should probably be discussed as part of a pre-proposal thread before
anything else happens.

Also, I think it would be valuable to add "covariant and contravariant
generic parameters" to the "unlikely" list (there's now a copy in the docs/
directory), as those have come up several times in the past and the core
team has expressed that they are pretty dead set against that feature.

Best,
Austin

On Sun, May 8, 2016 at 2:37 PM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Sorry, I misunderstood that you meant that the version of Concrete
> same-type requirement that does not introduce new syntax could be sent
> through as a bug request. It’s now done:
>
> [SR-1447] Concrete same-type requirements
> 
>
> On 08 May 2016, at 23:17, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I created two bug requests for Recursive protocol constraints and Nested
> generics and will write a proposal for Concrete same-type requirements.
>
> [SR-1445] Recursive protocol constraints
> 
>
> [SR-1446] Nested generics 
>
> On 03 May 2016, at 09:58, Douglas Gregor  wrote:
>
>
>
> Sent from my iPhone
>
> On May 2, 2016, at 3:58 PM, David Hart  wrote:
>
> I’d like to continue moving Completing Generics forward for Swift 3 with
> proposals. Can Douglas, or someone from the core team, tell me if the
> topics mentioned in *Removing unnecessary restrictions* require proposals
> or if bug reports should be opened for them instead?
>
>
> I'd classify everything in that section as a bug, so long as we're
> restricting ourselves to the syntax already present in the language.
> Syntactic improvements (e.g., for same-type-to-concrete constraints) would
> require a proposal.
>
>   - Doug
>
>
>
> On 03 Mar 2016, at 02:22, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> *Introduction*
>
> The “Complete Generics” goal for Swift 3 has been fairly ill-defined thus
> fair, with just this short blurb in the list of goals:
>
>
>- *Complete generics*: Generics are used pervasively in a number of
>Swift libraries, especially the standard library. However, there are a
>number of generics features the standard library requires to fully realize
>its vision, including recursive protocol constraints, the ability to make a
>constrained extension conform to a new protocol (i.e., an array of
>Equatable elements is Equatable), and so on. Swift 3.0 should provide
>those generics features needed by the standard library, because they affect
>the standard library's ABI.
>
> This message expands upon the notion of “completing generics”. It is not a
> plan for Swift 3, nor an official core team communication, but it collects
> the results of numerous discussions among the core team and Swift
> developers, both of the compiler and the standard library. I hope to
> achieve several things:
>
>
>- Communicate a vision for Swift generics, building on the original
>generics design document
>, so we
>have something concrete and comprehensive to discuss.
>- Establish some terminology that the Swift developers have been using
>for these features, so our discussions can be more productive (“oh, you’re
>proposing what we refer to as ‘conditional conformances’; go look over at
>this thread”).
>- Engage more of the community in discussions of specific generics
>features, so we can coalesce around designs for public review. And maybe
>even get some of them implemented.
>
>
> A message like this can easily turn into a centithread
> . To separate
> concerns in our discussion, I ask that replies to this specific thread be
> limited to discussions of the vision as a whole: how the pieces fit
> together, what pieces are missing, whether this is the right long-term
> vision for Swift, and so on. For discussions of specific language features,
> e.g., to work out the syntax and semantics of conditional conformances or
> discuss the implementation in compiler or use in the standard library,
> please start a new thread based on the feature names I’m using.
>
> This message covers a lot of ground; I’ve attempted a rough categorization
> of the various features, and kept the descriptions brief to limit the
> overall length. Most of these aren’t my ideas, and any syntax I’m providing
> is simply a way to express these ideas in code and is subject to change.
> Not all of these features will happen, either soon or ever, but they are
> intended to be a fairly complete whole that

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

[Brent Royal-Gordon via swift-evolution]

> 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

Re: [swift-evolution] [Opinion] Thoughts about the SE-0025 (Scoped Access Level) proposal

[Ross O'Brien via swift-evolution]

When you say you missed all the discussions and threads... you missed
probably the longest bikeshedding discussion we've had on Swift Evolution
so far.
First: no-one's ruled out a 'protected' access level yet. Equally, as far
as I recall, it hasn't been presented for review yet. It's neither accepted
nor rejected. How its type-based access nature works with Swift's
scope-based access system will be an interesting topic. Perhaps now's a
good time to start it.
Second: however ugly you find 'fileprivate', you understood what it meant.
Not knowing which of 'local' and 'private' was implicitly more private
drove a lot of that discussion; that's why 'fileprivate' won. It's also a
relative term - for example, since it would be pointless to declare a
protocol as 'local' in your hierarchy (since it would then be impossible
for another type to conform to it), the protocol would be declared as
'private' but would have 'fileprivate' visibility, which means you wouldn't
see 'fileprivate' perhaps as often as you're concerned about.

On Sun, May 8, 2016 at 9:13 PM, Vanderlei Martinelli via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello.
>
>
> I had a health problem and recently I needed a surgery because of it. Now
> I'm fine (yay!), but I missed all the discussions and threads at this time.
>
> Reading the SE-0025 proposal, which I find quite valid, I found it the
> (ugly) keyword `fileprivate` and the lack of a `protected` scope. I know it
> should be late for you to turn back, but below is my suggestion about the
> access level scopes the Swift language could implement:
>
>
> *public*
> Nothing to change. Symbols will be visible to the CONTAINING TYPE and ALL
> MODULES.
>
> *protected **
> Symbols visibility will be limited to the CONTAINING TYPE and DERIVED
> TYPES from the containing type. (Rookies calling `myView.layoutSubviews()`
> no more...)
>
> *internal*
> Nothing to change. Symbols will be visible to the CONTAINING TYPE and the
> CURRENT MODULE.
>
> *protected internal 
> Symbols visibility will be limited to the CONTAINING TYPE and DERIVED
> TYPES from the containing type or the CURRENT MODULE. (They will be
> `protected` when used by other modules, but `internal` when used by the
> current module.)
>
> *private*
> The symbols will be visible within the CONTAINING TYPE and the OTHER TYPES
> in the SAME FILE. (This is the `fileprivate` proposed in SE-0025.)
>
> *local 
> The symbols will be visible within the CONTAINING TYPE ONLY. (No other
> types accessing my variables anymore... This is the proposed `private`in
> SE-0025)
>
>
> *The items marked with * denote new access levels. The other remain as
> they are implemented in Swift 2.x*
>
>
> Well... That was it.
>
>
> Regards,
>
> Vanderlei Martinelli
>
>
> ___
> 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] multi-line string literals.

[Ricardo Parada via swift-evolution]

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). 

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



> 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

Re: [swift-evolution] [Manifesto] Completing Generics

[David Hart via swift-evolution]

Sorry, I misunderstood that you meant that the version of Concrete same-type 
requirement that does not introduce new syntax could be sent through as a bug 
request. It’s now done:

[SR-1447] Concrete same-type requirements 


> On 08 May 2016, at 23:17, David Hart via swift-evolution 
>  wrote:
> 
> I created two bug requests for Recursive protocol constraints and Nested 
> generics and will write a proposal for Concrete same-type requirements.
> 
> [SR-1445] Recursive protocol constraints 
> 
> 
> [SR-1446] Nested generics 
>> On 03 May 2016, at 09:58, Douglas Gregor > > wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On May 2, 2016, at 3:58 PM, David Hart > > wrote:
>> 
>>> I’d like to continue moving Completing Generics forward for Swift 3 with 
>>> proposals. Can Douglas, or someone from the core team, tell me if the 
>>> topics mentioned in Removing unnecessary restrictions require proposals or 
>>> if bug reports should be opened for them instead?
>> 
>> I'd classify everything in that section as a bug, so long as we're 
>> restricting ourselves to the syntax already present in the language. 
>> Syntactic improvements (e.g., for same-type-to-concrete constraints) would 
>> require a proposal. 
>> 
>>   - Doug
>> 
>> 
>>> 
 On 03 Mar 2016, at 02:22, Douglas Gregor via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Hi all,
 
 Introduction
 
 The “Complete Generics” goal for Swift 3 has been fairly ill-defined thus 
 fair, with just this short blurb in the list of goals:
 
 Complete generics: Generics are used pervasively in a number of Swift 
 libraries, especially the standard library. However, there are a number of 
 generics features the standard library requires to fully realize its 
 vision, including recursive protocol constraints, the ability to make a 
 constrained extension conform to a new protocol (i.e., an array of 
 Equatable elements is Equatable), and so on. Swift 3.0 should provide 
 those generics features needed by the standard library, because they 
 affect the standard library's ABI.
 This message expands upon the notion of “completing generics”. It is not a 
 plan for Swift 3, nor an official core team communication, but it collects 
 the results of numerous discussions among the core team and Swift 
 developers, both of the compiler and the standard library. I hope to 
 achieve several things:
 
 Communicate a vision for Swift generics, building on the original generics 
 design document 
 , so we have 
 something concrete and comprehensive to discuss.
 Establish some terminology that the Swift developers have been using for 
 these features, so our discussions can be more productive (“oh, you’re 
 proposing what we refer to as ‘conditional conformances’; go look over at 
 this thread”).
 Engage more of the community in discussions of specific generics features, 
 so we can coalesce around designs for public review. And maybe even get 
 some of them implemented.
 
 A message like this can easily turn into a centithread 
 . To separate 
 concerns in our discussion, I ask that replies to this specific thread be 
 limited to discussions of the vision as a whole: how the pieces fit 
 together, what pieces are missing, whether this is the right long-term 
 vision for Swift, and so on. For discussions of specific language 
 features, e.g., to work out the syntax and semantics of conditional 
 conformances or discuss the implementation in compiler or use in the 
 standard library, please start a new thread based on the feature names I’m 
 using.
 
 This message covers a lot of ground; I’ve attempted a rough categorization 
 of the various features, and kept the descriptions brief to limit the 
 overall length. Most of these aren’t my ideas, and any syntax I’m 
 providing is simply a way to express these ideas in code and is subject to 
 change. Not all of these features will happen, either soon or ever, but 
 they are intended to be a fairly complete whole that should mesh together. 
 I’ve put a * next to features that I think are important in the nearer 
 term vs. being interesting “some day”. Mostly, the *’s reflect features 
 that will have a significant impact on the Swift standard library’s design 
 and implementation.
 
 Enough with the disclaimers; it’s time to talk features.
 
 Removing unnecessary restrictions
 
 There are a number of restrictions to the use of generics that fall out of 
 the implementation in the Swift comp

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

[Andrew Trick via swift-evolution]

> On May 7, 2016, at 6:43 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> If I read Andrew’s post correctly it sounds like it may also be of use to the 
> optimizer in some cases.


I’ll just requote Dave’s example, which made perfect sense to me (so I’m not 
sure why there’s an argument):

> To me that means, if the behavior of “f” only depends on
> data reachable through this array, and f makes no mutations, then in
> this code, the two calls to f() are guaranteed have the same effect.
> 
>  func g(a: [T]) {
>var vc = MyViewController(a)
>vc.f() // #1
>h()
>vc.f() // #2
> }
> 
> But clearly, the only way that can be the case is if T is actually
> immutable (and contains no references to mutable data), because
> otherwise anybody can write:
> 
>class X { ... }
>let global: [X] = [ X() ]
>func h() { global[0].mutatingMethod() }
>g(global)
> 
> Conclusion: your definition of PureValue, as written, implies conforming
> reference types must be immutable.  I'm not saying that's necessarily
> what you meant, but if it isn't, you need to try to define it again.

Yes, of course. If a PureValue contains a reference it must be immutable or 
only mutated when uniquely referenced.

There are other ways to communicate what the optimizer needs. I think the more 
interesting question is how users should express the value semantics of their 
types.

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

Re: [swift-evolution] [Manifesto] Completing Generics

[David Hart via swift-evolution]

I created two bug requests for Recursive protocol constraints and Nested 
generics and will write a proposal for Concrete same-type requirements.

[SR-1445] Recursive protocol constraints 

[SR-1446] Nested generics 
> On 03 May 2016, at 09:58, Douglas Gregor  wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On May 2, 2016, at 3:58 PM, David Hart  > wrote:
> 
>> I’d like to continue moving Completing Generics forward for Swift 3 with 
>> proposals. Can Douglas, or someone from the core team, tell me if the topics 
>> mentioned in Removing unnecessary restrictions require proposals or if bug 
>> reports should be opened for them instead?
> 
> I'd classify everything in that section as a bug, so long as we're 
> restricting ourselves to the syntax already present in the language. 
> Syntactic improvements (e.g., for same-type-to-concrete constraints) would 
> require a proposal. 
> 
>   - Doug
> 
> 
>> 
>>> On 03 Mar 2016, at 02:22, Douglas Gregor via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Introduction
>>> 
>>> The “Complete Generics” goal for Swift 3 has been fairly ill-defined thus 
>>> fair, with just this short blurb in the list of goals:
>>> 
>>> Complete generics: Generics are used pervasively in a number of Swift 
>>> libraries, especially the standard library. However, there are a number of 
>>> generics features the standard library requires to fully realize its 
>>> vision, including recursive protocol constraints, the ability to make a 
>>> constrained extension conform to a new protocol (i.e., an array of 
>>> Equatable elements is Equatable), and so on. Swift 3.0 should provide those 
>>> generics features needed by the standard library, because they affect the 
>>> standard library's ABI.
>>> This message expands upon the notion of “completing generics”. It is not a 
>>> plan for Swift 3, nor an official core team communication, but it collects 
>>> the results of numerous discussions among the core team and Swift 
>>> developers, both of the compiler and the standard library. I hope to 
>>> achieve several things:
>>> 
>>> Communicate a vision for Swift generics, building on the original generics 
>>> design document 
>>> , so we have 
>>> something concrete and comprehensive to discuss.
>>> Establish some terminology that the Swift developers have been using for 
>>> these features, so our discussions can be more productive (“oh, you’re 
>>> proposing what we refer to as ‘conditional conformances’; go look over at 
>>> this thread”).
>>> Engage more of the community in discussions of specific generics features, 
>>> so we can coalesce around designs for public review. And maybe even get 
>>> some of them implemented.
>>> 
>>> A message like this can easily turn into a centithread 
>>> . To separate 
>>> concerns in our discussion, I ask that replies to this specific thread be 
>>> limited to discussions of the vision as a whole: how the pieces fit 
>>> together, what pieces are missing, whether this is the right long-term 
>>> vision for Swift, and so on. For discussions of specific language features, 
>>> e.g., to work out the syntax and semantics of conditional conformances or 
>>> discuss the implementation in compiler or use in the standard library, 
>>> please start a new thread based on the feature names I’m using.
>>> 
>>> This message covers a lot of ground; I’ve attempted a rough categorization 
>>> of the various features, and kept the descriptions brief to limit the 
>>> overall length. Most of these aren’t my ideas, and any syntax I’m providing 
>>> is simply a way to express these ideas in code and is subject to change. 
>>> Not all of these features will happen, either soon or ever, but they are 
>>> intended to be a fairly complete whole that should mesh together. I’ve put 
>>> a * next to features that I think are important in the nearer term vs. 
>>> being interesting “some day”. Mostly, the *’s reflect features that will 
>>> have a significant impact on the Swift standard library’s design and 
>>> implementation.
>>> 
>>> Enough with the disclaimers; it’s time to talk features.
>>> 
>>> Removing unnecessary restrictions
>>> 
>>> There are a number of restrictions to the use of generics that fall out of 
>>> the implementation in the Swift compiler. Removal of these restrictions is 
>>> a matter of implementation only; one need not introduce new syntax or 
>>> semantics to realize them. I’m listing them for two reasons: first, it’s an 
>>> acknowledgment that these features are intended to exist in the model we 
>>> have today, and, second, we’d love help with the implementation of these 
>>> features.
>>> 
>>> 
>>> *Recursive protocol constraints
>>> 
>>> Currently, an associated type cannot be required to co

[swift-evolution] NSRange and Range

[David Hart via swift-evolution]

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?

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

Re: [swift-evolution] [swift-corelibs-dev] Change in String.CharacterView.Index?

[Dennis Weissmann via swift-evolution]

Hey Joe,

The collection index model changed:

https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md

You now need to ask the collection for the next index:

let a = “Hello, World"
let secondIndex = a.characters.index(after: a.characters.startIndex)
print(a.characters[secondIndex]) // prints "e"

- Dennis

> On May 8, 2016, at 7:58 PM, Joseph Bell via swift-corelibs-dev 
>  wrote:
> 
> Howdy,
> 
> I've been building the latest Swift 3.0 and noticed that between Apr 25 and 
> today that String.CharacterView.Index.advance(by:) is no longer available.
> 
> This runs with an Apr 25 build (Swift 255544591c to be exact)
> let string:String = "Hello, world!"
> print(string.startIndex)
> print(string.startIndex.advanced(by:1))
> 
> It fails with a build today (May 8, Swift 26fcf1ab4a):
> test.swift:3:14: error: value of type 'Index' (aka 
> 'String.CharacterView.Index') has no member 'advanced'
> print(string.startIndex.advanced(by:1))
>   ~~~^~ 
> 
> I don't know who runs swiftdoc.org  but it is handy, 
> and shows advanced(by:) a valid method:
> http://swiftdoc.org/v3.0/type/String.CharacterView.Index/ 
> 
> 
> Not sure what I'm missing here!
> 
> Thanks,
> Joe
> 
> 
> -- 
> Joseph Bell
> http://dev.iachieved.it/iachievedit/ 
> @iachievedit
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[swift-evolution] [Opinion] Thoughts about the SE-0025 (Scoped Access Level) proposal

[Vanderlei Martinelli via swift-evolution]

Hello.


I had a health problem and recently I needed a surgery because of it. Now
I'm fine (yay!), but I missed all the discussions and threads at this time.

Reading the SE-0025 proposal, which I find quite valid, I found it the
(ugly) keyword `fileprivate` and the lack of a `protected` scope. I know it
should be late for you to turn back, but below is my suggestion about the
access level scopes the Swift language could implement:


*public*
Nothing to change. Symbols will be visible to the CONTAINING TYPE and ALL
MODULES.

*protected **
Symbols visibility will be limited to the CONTAINING TYPE and DERIVED TYPES
from the containing type. (Rookies calling `myView.layoutSubviews()` no
more...)

*internal*
Nothing to change. Symbols will be visible to the CONTAINING TYPE and the
CURRENT MODULE.

*protected internal 
Symbols visibility will be limited to the CONTAINING TYPE and DERIVED TYPES
from the containing type or the CURRENT MODULE. (They will be `protected`
when used by other modules, but `internal` when used by the current module.)

*private*
The symbols will be visible within the CONTAINING TYPE and the OTHER TYPES
in the SAME FILE. (This is the `fileprivate` proposed in SE-0025.)

*local 
The symbols will be visible within the CONTAINING TYPE ONLY. (No other
types accessing my variables anymore... This is the proposed `private`in
SE-0025)


*The items marked with * denote new access levels. The other remain as they
are implemented in Swift 2.x*


Well... That was it.


Regards,

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

[swift-evolution] [Idea] Represent a point in time as a Swift immutable scalar type TimePoint

[Steve Weller via swift-evolution]

Proposal

Represent a point in time as a Swift immutable scalar type TimePoint

Motivation

The representation of time and calculations involving time are fundamental to 
the correct functioning of all computer systems. If the language can express 
and manipulate points in time in a consistent and well-defined way, then the 
user will make fewer programming errors, the reliability and security of the 
system will be improved, and the scope of applications for that language will 
increase.

Representing and manipulating points in time has historically been an 
error-prone endeavor. Problems include:

* Precision: lack of or unknown stored precision, loss during calculations, 
floating point quirks
* Range: Underflow or overflow during calculation due to unexpectedly small 
range or unsigned representation 
* Lack of built-in representations: distant past and distant future usually 
require values with special meaning
* Use of inappropriate operators on scalar types that are used to store a 
representation of a point in time


Proposed Solution

The Swift language should provide an immutable scalar type TimePoint that can 
represent only a point in time. Additionally it should provide a mutable signed 
scalar type TimeOffset that can represent only the difference between two 
TimePoints.

TimePoint is approximated by the following enumeration:

enum TimePoint : Strideable, RawRepresentable, Hashable {
case DistantPast, 
case DistantFuture,
case At(Int64, UInt64)   // Seconds, nanos
}

TimePoint is similar to NSDate. However, its underying storage strategy is 
hidden from the user. To access the value, rawValue must be called to get a 
tuple (seconds: Int64, nanos: UInt64).

TimePoint provides the guarantee that it has sufficient resolution and range 
for all practical purposes (precision to nanos worst case, range of the order 
of the age of the universe).

The Stride of a TimePoint is of signed type TimeOffset. TimeOffset is 
approximated by the following struct:

struct TimeOffset : Comparable, RawRepresentable, Hashable {
var seconds:Int64
var nanos: UInt64
} 

The compiler is aware of the meaning of .DistantFuture and .DistantPast and can 
warn of inappropriate or nonsensical use. For example, the following can never 
be true:

if t > TimePoint.DistantFuture { return }

Since .DistantFuture and .DistantPast are not special values, TimePoint behaves 
as expected across its entire range.

The underlying storage can be made efficient since it is opaque. Since common, 
practical points in time are specified to units larger than nanos, and they do 
not need the full range, many zero or fixed bit values can be encoded into a 
small space, while rare or impractical points in time can still be faithfuly 
recorded.

TimePoint and TimeOffset have appropriate initializers, getters, and methods 
(TBD) to allow them to interoperate with other types.

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

[swift-evolution] Change in String.CharacterView.Index?

[Joseph Bell via swift-evolution]

Howdy,

I've been building the latest Swift 3.0 and noticed that between Apr 25 and
today that String.CharacterView.Index.advance(by:) is no longer available.

This runs with an Apr 25 build (Swift 255544591c to be exact)
let string:String = "Hello, world!"
print(string.startIndex)
print(string.startIndex.advanced(by:1))

It fails with a build today (May 8, Swift 26fcf1ab4a):
test.swift:3:14: error: value of type 'Index' (aka
'String.CharacterView.Index') has no member 'advanced'
print(string.startIndex.advanced(by:1))
  ~~~^~ 

I don't know who runs swiftdoc.org but it is handy, and shows advanced(by:)
a valid method:
http://swiftdoc.org/v3.0/type/String.CharacterView.Index/

Not sure what I'm missing here!

Thanks,
Joe


-- 
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Sheaver via swift-evolution]

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 
>  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 
> mailto: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 fact using a combination of Swift, 
> Objective-C, C, C++, various flavors of assembly, and more. The goal is to 
> present the existing API of Foundation in a way that fits in with the 
> language today while allowing us to iteratively improve it over time.
> 
> Perhaps my concern is a higher level - I don't understand where Foundation is 
> envisioned going.
> 
> From my perspective, Foundation is highly coupled to Apple platforms and 
> Objective-C on one side, and part of the Swift standard library on the other. 
> Perhaps long-term Foundation should be split into two new things - a core 
> library for cross-platform swift development, and the infrastructure for 
> Objective-C interoperability on apple platforms only.
> 
> -DW
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal/Pitch] Function decorators

[Karl Wagner via swift-evolution]

> On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution 
>  wrote:
> 
> Hi swift-evolution,
> 
> I want to apologize in advance for my clumsy English. It's (obviously) not my 
> first language.
> 
> Recent discussion about property behaviours reminded me of function 
> decorators in Python. I think decorators can nicely fit in Swift, too.
> 
> First, a bit of explanation for the uninitiated. Decorator is a function that 
> transform other function - it receives some function and returns a function 
> of the same signature. Lets make some dead simple decorator:
> 
> typealias Decorated = (Double, Double) -> Double
> 
> func hiDecorator(fn: Decorated) -> Decorated {
> return { x, y in
> print("Hi from decorator!")
> return fn(x, y)
> }
> } 
> 
> func multiply(a: Double, _ b: Double) -> Double {
>return a * b
> }
> 
> let decoratedMultiply = hiDecorator(multiply)
> print("Result: \(decoratedMultiply(2, 3))") 
> 
> 
> The above code should print:
> Hi from decorator!
> Result: 6
> 
> We can use decorators with the current Swift, but they're a bit cumbersome - 
> either we need to store decorated function and remember to use it instead of 
> the original one, or remember to do the decoration on every call.
> 
> Instead, we can write something like this:
> 
> [hiDecorator]
> func multiply(a: Double, _ b: Double) -> Double {
> return a * b
> }
> 
> ... and that code should be transformed into following during compilation:
> 
> func multiply(a: Double, _ b: Double) -> Double {
>  let fn: (Double, Double) -> Double { _a, _b in
>  return _a * _b
>  }
>  
>  let decorated = hiDecorator(fn) 
>  return decorated(a, b)
> }
> 
> Outside, the function looks like before, so the change is compatible with 
> virtual or interface extension functions.
> 
> Sometimes we'll need to pass some additional data to the decorator. That's 
> fine, as long as the last argument is the target function:
> 
> func logUsage(fnName: String, fn: (I) -> O) -> ((I) -> O) {
> return { _i in
> print("Function \(fnName) enter")
> defer { print("Function \(fnName) exit") }
> return fn(_i)
> }
> }
> 
> Let's use it:
> 
> [logUsage("increment")]
> func increment(a: Int) -> Int { return a + 1 }
> 
> [logUsage("justPrint")]
> func justPrint(s: String) { print(s) }
> 
> In the above code, the compiler should generate internal decorator call by 
> combining provided parameter and decorated function.
> 
> 
> Why decorators?
> 
> It's important to say that proposed decorators change are pure syntactic 
> sugar. Everything we can do with this change can be accomplished with the 
> current Swift language. But, it gives to programmer a tool to express 
> intentions more clearly and move repeating code away. 
> 
> Sometimes decorators are just a convenient way to quickly add code. In the 
> example above, logging is added with just one line of code and can be easily 
> removed - the function body is not changed. 
> 
> Sometimes decorators can be used as a poor man dependency injection 
> mechanism, so we can write functions like this:
> 
> // if conn is nil, dbInit decorator will provide (global) one, and properly 
> close it after doSomeDbWork exits
> [dbInit]
> func doSomeDbWork(conn: DbConnection? = nil) { ... } 
> 
> 
> We can use decorators in the standard library to, in a way, extend language:
> 
> [asyncMain]
> func doSomething() { ... }  // this function will be posted to main queue
> 
> [synchronized]
> func foo() { ... } // synchronized decorator uses either objc_sync_enter/exit 
> or post on some queue to ensure mutual exclusion
> 
> Or to do some more exotic operations:
> 
> [repeatUntilDone(maxAttempt: 5)]
> func connectToServer(url: String) -> Bool { ... }
> 
> Abstract functions are frowned upon in Swift community, but if we can't live 
> without it, we can signal our intent more clearly with decorator:
> 
> class T {
>  [abstract] func bar() {} // abstract decorator will assert on call
> }
> 
> Etc, etc. Sounds interesting?
> 
> Alex
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


Given that we might be doing "property behaviours” 
(https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md
 
),
 which are basically property decorators, it probably makes sense to look at 
how that could work for function decorators.

After all, you could create a property behaviour around a closure and use that 
as a kind of function decorator. It would just be messy.

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

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Geordie J via swift-evolution]

Comments below

> Am 05.05.2016 um 20:22 schrieb Dennis Weissmann via swift-evolution 
> :
> 
> Following a short discussion with positive feedback on 
> [swift-users](http://thread.gmane.org/gmane.comp.lang.swift.user/1812 
> ) I’d like to 
> discuss the following:
> 
> Tuples should be destructible into their components in parameter lists.
> 
> Consider the following code:
> 
> let a = [0,1,2,3,4,5,6,7,8,9]
> let b = [0,1,2,3,4,5,6,7,8,9]
> 
> let c = zip(a,b).reduce(0) { acc, tuple in
>   acc + tuple.0 + tuple.1
> }
> 
> tuple is of type (Int, Int).
> 
> The problem is that the calculation is not very comprehensible due to .0 and 
> .1. That’s when destructuring tuples directly in the parameter list comes 
> into play:
> 
> let c = zip(a,b).reduce(0) { acc, (valueA, valueB) in
>   acc + valueA + valueB
> }

+1 I think this is a great way to go about it.

> 
> The above is what I propose should be accepted by the compiler (but currently 
> isn’t).
> 
> Currently tuple destructuring is possible like this:
> 
> let c = zip(a,b).reduce(0) { (acc, tuple) in
>   let (valueA, valueB) = tuple
>   return acc + valueA + valueB
> }
> 
> This is not about saving one line ;-). I just find it much more intuitive to 
> destructure the tuple in the parameter list itself.

Agreed

> 
> The same thing could be done for functions:
> 
> func takesATuple(someInt: Int, tuple: (String, String))
> 
> Here we also need to destructure the tuple inside the function, but the 
> intuitive place (at least for me) to do this would be the parameter list.
> 
> In the following example I'm making use of Swift’s feature to name parameters 
> different from their labels (for internal use inside the function, this is 
> not visible to consumers of the API):
> 
> func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))


I’m not such a fan of this though. I realize what I’m about to write here is 
discussing a slightly different point but bear with me: I was under the 
impression it was already possible to do something like this (maybe only 
possible with typealiases):

func takesATuple(someInt: Int, tuple: (valueA: String, valueB: String)) {}

I find that syntax readable and extensible: you can make a type alias for your 
tuple type '(valueA: String, valueB: String)‘, you can then use it like this:

func takesATuple(someInt: Int, tuple: MyAliasedTupleType) {
  print(tuple.valueA)
}

It’s true that you still have the ‚overhead‘ of having to type tuple. before 
accessing its members. But this is almost always what I want (hopefully you’d 
never actually name your tuple ‚tuple‘, instead it’d be a logical namespace for 
what it contains). Do you have a real-world example where you’d need this? To 
me it seems that in a case like this the API that produced the tuple would need 
refining rather than the language itself.

> 
> Here valueA and valueB would be directly usable within the function. The 
> tuple as a whole would not be available anymore.
> 
> 
> Now it’s your turn!
> 
> 1. What do you think?
> 2. Is this worth being discussed now (i.e. is it implementable in the Swift 3 
> timeframe) or should I delay it?
> 
> Cheers,
> 
> - Dennis
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Idea: Allow/require "let" in property setter name declarations

[Geordie J via swift-evolution]

Comments below

> Am 06.05.2016 um 13:48 schrieb Haravikk via swift-evolution 
> :
> 
> Actually a setter has more in common with a function, in which case the let 
> implicit, the difference is that a setters type is also implicit. In fact, 
> you don’t even need to specify a name in a setter at all, as the default is 
> newValue and you can just use that.
> 
> I’m more curious whether we even need a named new value at all, or if setters 
> should just look like the following instead:
> 
>   set { sideLength = $0 / 4.0 }

This is great!
Why not have the opportunity to name the variable like in closures, but have it 
default to $0:

class Square {
  var sideLength: Double = 0.0
  var perimeter: Double {
set { newPerimeter in
  sideLength = newPerimeter / 4.0
}
  }
}

> 
> As this would be more consistent with anonymous closure arguments, rather 
> than using newValue which is arbitrary. I’ve never encountered an occasion 
> where I’ve needed a custom name, and I only use external vs internal names on 
> functions where I can make an external name that flows better, but perhaps 
> doesn’t mesh with my other internal variable names.
> 
>> On 6 May 2016, at 12:09, Ian Partridge via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Currently, the syntax for explicitly naming property setters is:
>> 
>> class Square {
>>   var sideLength: Double = 0.0
>> 
>>   var perimeter: Double {
>> get {
>>   return sideLength * 4.0
>> }
>> set(newPerimeter) { // declares newPerimeter parameter, "let" not allowed
>>   sideLength = newPerimeter / 4.0
>> }
>>   }
>> }
>> 
>> Compare this with how extraction of associated values from enumerations 
>> looks:
>> 
>> enum ServerResponse {
>>   case Failure(String)
>>   case Result(Int)
>> }
>> let response = ServerResponse.Result(404)
>> 
>> switch response {
>> case .Failure(let reason): // let is required here
>>   print(reason)
>> case .Result(let code):
>>   print(code)
>> }
>> 
>> For consistency, would it be better to allow/require:
>> 
>> class Square {
>>   var sideLength: Double = 0.0
>> 
>>   var perimeter: Double {
>> get {
>>   return sideLength * 4.0
>> }
>> set(let newPerimeter) {  // declares newPerimeter parameter
>> sideLength = newPerimeter / 4.0
>> }
>>   }
>> }
>> 
>> The idea would apply to didSet{} and willSet{} too.
>> 
>> --
>> Ian Partridge
>> 
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Josh Parmenter via swift-evolution]

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

Sent from my iPhone

On May 8, 2016, at 00:41, David Waite via swift-evolution 
mailto: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 fact using a combination of Swift, 
Objective-C, C, C++, various flavors of assembly, and more. The goal is to 
present the existing API of Foundation in a way that fits in with the language 
today while allowing us to iteratively improve it over time.

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

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

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

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

[L Mihalkovic via swift-evolution]

>>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 today
>>shouldn't prevent us from adopting the right model for values and
>>references.
>> 
>> I think that depends on what you mean by this. If you mean providing a 
>> default
>> equality of reference identity for reference types I disagree. I think that
>> should wait until the language reaches a place where there is no good reason 
>> to
>> write value semantic reference types. And I believe the boilerplate currently
>> required to wrap them in a struct is sufficiently burdensome that this is not
>> the case yet.
> 
> As I've said, we can't wait.  We should make the change and use that to
> drive development of the necessary features to reduce the burden of
> writing optimized code.  
> 
> Remember that the only value semantic reference types are immutable, so
> the struct rendition of such types has only immutable properties.
> Personally, I don't think that transforming
> 
>struct X {
>  ...
>private:
>  let prop1: Type1
>  let prop2: Type2
>  let prop2: Type3
>}
> 
> into
> 
>struct X {
>   ...
>private:
>  class Storage {
>let prop1: Type1
>let prop2: Type2
>let prop2: Type3
>  }
>  let value: Storage
>}
> 
> is so awful if you find you need to optimize away some reference
> counting manually; you just need to add “.value” to property accesses in
> X's methods, and this doesn't require any forwarding.
> 


FWIW +1. pandora’s box never fully seals back... so it is easier to force 
explicit extra syntax early and later decide that under some special conditions 
the requirements can be relaxed. Considering the timeline for 3.00 as well as 
its associated stake, the aforementioned syntax represents a coherent (if not 
yet fully minimizing of user’s efforts) programing model that could be lived 
with for the foreseeable future, all the while not closing the door on certain 
types of future simplification. 

For example the following syntax is a straw man representation of what could be 
done at a future date to reduce the boilerplate:

   struct X {
 ...
   private:
 @strawman_syntax1 let prop1: Type1
 let prop2: @strawman_syntax2 Type2
 strawman_syntax3 let prop2: Type3
   }

To extend on ‘value semantic reference type’, esthetic considerations would 
push me towards a solution expressing it at the usage site (like in the straw 
man syntax above), rather than via the introduction of a new protocol to be 
used at the definition site. i.e. favoring "my usage here of Type1 instances is 
to be construed as having value semantic” (with the compiler or me crafting a 
different definition of identity) over the less self documenting “Class Type1 
is for all eternity carrying value semantic”, which ultimately seems more 
confusing to me. 
I call it an esthetic argument as it is based on nothing else than a personal 
view on symmetry: (for no good reason) I value symmetry as the sign of a *good* 
design. Struct and Class are structural constructs to express a specific notion 
in the language. Out of my desire for symmetry I would expect that anything 
altering my perception of this notion would have to be equally conveyed within 
the structure of the language. Resorting to protocol compliance to do the same 
strikes me as the kind of deep imbalance I try to avoid.

/LM

>> 
>>So far, I still don't believe that introducing a “pure values”
>>distinction is adding simplicity and clarity. To me it looks like
>>a needless wrinkle.
>> 
>> Fair enough. I suspect that many folks who have been strongly influenced by
>> functional programming may have a different opinion (btw, I don’t mean to 
>> imply
>> anything about the degree to which functional programming has or has not
>> influenced your opinion).
> 
> -- 
> -Dave
> ___
> swift-evolution mailing list

Re: [swift-evolution] [Pitch] alternative multiline string literals

[L Mihalkovic via swift-evolution]

Added details about the prototype. 



// This code sample and prototype implementation (implemented in patch against 
the 3.0
// branch of the swift compiler) explores a possible syntax based on ideas 
discussed in
// the swift-evolution mailing list at
//  http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133
//
// The proposed syntax uses a combination of two characters to signal the start 
and end 
// of a multiline string in the source code:   _" contents "_ 
// 
// Additionally, the syntax introduces a new @string_literal() attibute that 
can be used
// to semantically tag the contents of a multiline string literal. The hope is 
that this
// attribute would be used by IDEs for custom validation/formatting of the 
contents of 
// long string literals, as well as possibly be accessible at runtime via an 
extended
// mirror/reflection mechanism.

// Tagging literal contents
@string_literal("json")   let att1 = _"{"key1": "stringValue"}"_
@string_literal("text/xml")   let att2 = _""_
@string_literal("swift_sil")  let att3 = _" embedded SIL contents?! "_

// The following alternatives for placement of the attribute have been looked 
into 
// and so far rejected for seemingly not fitting as closely with other 
attribute usage 
// patterns in the Swift grammar:
// 
// let att2 : @string_literal("text/xml") String  = _" ... "_  // Conveys the 
impressing that the type is annotated rather than the variable
// let att2 = @string_literal("text/xml") _" ... "_// Appealing, 
but without any precedent in the Swift grammar
//

// checking that nothing is broken
let s0 = "s0"

// The default swift syntax requires that quotes be escaped
let s1 = "{\"key1\": \"stringValue\"}"

// The proposed syntax for multiline strings works for single line strings as 
well (maybe it 
// should not) and does not mandate that enclosed single quote characters be 
escaped
let s2 = _"{"v2"}"_

// When dealing with long blocks of embedded text, it seems natural to want to 
describe them
// as close as possible to the contents. The proposed syntax supports inserting 
a comment
// just before the data it documents. This allows the comment indentation to 
match exactly
// that of the string.
let s3 =
/* this is a template */
_"{"key3": "stringValue"}"_

// 

// The following section explores different ways to deal with leading spaces

let s4 =
/* this is (almost) the same template */
_"
{
  "key4": "stringValue"
  , "key2": "stringValue"
}
"_

let equivS4 = 
"\n"
"{\n" +
"  \"key4\": \"stringValue\"\n" +
"  , \"key2\": \"stringValue\"\n" +
"}\n" +
"\n"

//TODO: fix the leading spaces
let s5 =
  /* this is exactly the same template as s5 */
  _"
  {
"key5": "stringValue"
  }
  "_

//TODO: fix the leading spaces
let s6 =
  /* this is exactly the same template as s5 */
  _"
  |{
  |  "key6": "stringValue"
  |  , "key2": "stringValue"
  |}
  "_


I would appreciate any input on the realism/degree of difficulties of pursuing 
something like the following (swift_sil being a built in reserved attribute 
value):

@string_literal(swift_sil)  let att3 = _" embedded SIL contents?! "_

The train of thoughts is to try and identify a “simple” pathway for something 
akin to rust macros or jai’s “do this during compilation” (possible long term 
replacement for .gyb?!)


> On May 7, 2016, at 8:20 PM, L Mihalkovic  wrote:
> 
> Please accept my apologies for the repeat… I seem to have more trouble with 
> my emails than the brilliant codebase this team has produced.
> Best regards
> LM/
> 
> ——
> 
> Wanting to test the validity of some of the arguments I read on the main 
> proposal, I worked on my own prototype. I think there is more freedom than 
> seem to have been identified so far.
> 
> The syntax I am exploring is visible here: 
> https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c 
> 
> 
> There are still a couple of things that do not work 
> serialization of the @string_literal attribute
> type checker code for the @string_literal attribute 
> skipping leading spaces on each lines, based on the indentation of the first 
> line
> removing some of the extra EOL (rule to be defined)
> 
> The following works:
> comment before the literal data
> @string_literal(“”). At the moment the attribute value is a 
> string_literal, maybe a identifier would be better, and maybe it should be 
> @string_literal(type: “”), so that other properties can be added. I 
> persist in thinking that a lot of good can come from being able to tag the 
> contents of string literal (e.g. XML schema validation, custom syntax 
> coloring, … )
> the code is based on a string_multiline_literal tag to make these extension 
> formally visible in the grammar 
> no need to prefix each line (although it will be possible to use | as a 
> margin)
> 


>From a mor

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

[Tyler Fleming Cloutier via swift-evolution]

> On May 7, 2016, at 10:39 PM, Dave Abrahams  wrote:
> 
> 
> on Sat May 07 2016, Tyler Fleming Cloutier  > wrote:
> 
>>> On May 7, 2016, at 12:52 PM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Fri May 06 2016, Tyler Fleming Cloutier  wrote:
>>> 
>> 
   On May 6, 2016, at 6:54 PM, Dave Abrahams via swift-evolution
wrote:
 
   on Fri May 06 2016, Matthew Johnson  wrote:
 
   On May 6, 2016, at 7:48 PM, Dave Abrahams via swift-evolution
wrote:
 
   Swift’s collections also accomplish this through copying, but only 
 when
   the
   elements they contain also have the same property. 
 
   Only if you think mutable class instances are part of the value of the
   array that stores references to those class instances. As I said
   earlier, you can *take* that point of view, but why would you want to?
   Today, we have left that question wide open, which makes the whole
   notion of what is a logical value very indistinct. I am proposing to
   close it.
 
   On the other hand, it is immediately obvious that non-local mutation
   is quite possibly in the elements of a Swift Array unless
   they are all uniquely referenced.
 
   If you interpret the elements of the array as being *references* to
   objects, there is no possibility of non-local mutation. If you
   interpret the elements as being objects *themselves*, then you've got
   problems.
 
 This does not make sense, because you’ve got problems either way. You are
 arguing, essentially, that everything is a value type because
 references/pointers are a value. 
>>> 
>>> I am arguing that every type can be viewed as a value, allowing us to
>>> preserve a sense in which Array has value semantics irrespective of
>>> the details of T.
>>> 
 If that were the case then the *only* valid way to compare the
 equality of types would be to compare their values. Overriding the
 equality operator would inherently violate the property of
 immutability, i.e. two immutable objects can change their equality
 even without mutation of their “values".
>>> 
>>> Not at all.  In my world, you can override equality such that it
>>> includes referenced storage when either:
>>> 
>>> 1. the referenced storage will not be mutated
>>> 2. or, the referenced storage will only mutated when uniquely-referenced.
>>> 
 
 func ==(lhs, rhs) {
 ...
 }
 
 class MyClass {
 var a: Int
 ...
 
 } 
 
 let x = MyClass(a: 5)
 let y = MyClass(a: 5)
 
 x == y // true
 y.a = 6
 x == y // false
>>> 
>>> I don't understand what point you're trying to make, here.  I see that x
>>> and y are immutable. Notwithstanding the fact that the language tries to
>>> hide the difference between a reference and the instance to which it
>>> refers from the user (the difference would be clearer if you had to
>>> write y->a = 6 as in C, but it's still there), that immutability doesn't
>>> extend beyond the variable binding.  The class instance to which y
>>> refers, as you've ably demonstrated, is mutable.
>> 
>> The point I’m trying to make is that in the above code, I am able to
>> violate rule 1 of your world insofar as I am including referenced
>> storage in my definition of equality which can be mutated even though
>> my reference is immutable.
> 
> Sorry, I guess I don't understand what difference it makes that it's
> possible to write code that violates my rules.  It's not news to me, as
> I'm sure you knew when you posted it.
> 
   Are you arguing that reference types should be equatable by default,
   using
   equality of the reference if the type does not provide a custom
   definition of
   equality?
 
   Yes!!
 
 Custom definitions of equality, inherently, decouple immutability from
 equality,
>>> 
>>> Not a bit.  They certainly *can* do that, if we allow it, but I am
>>> proposing to ban that.  There are still useful custom definitions of
>>> equality as I have outlined above.
>> 
>> If you’re proposing to ban that, then I may have misunderstood your
>> position. I think we are in agreement on that, however… (more below)
>> 
>>> 
 as shown above. Swift makes it appear as though references and values
 are on the same level in a way that C does not.
>>> 
>>> Yep.  It's an illusion that breaks down at the edges and can be really
>>> problematic if users fully embrace it.  You can't write a generic
>>> algorithm with well-defined semantics that does mutation-by-part on
>>> instances of T without constraining T to have value or reference semantics.
>>> 
>>> I am not advocating that we require “y->a” for class member access, but
>>> I *am* suggesting that we should accept the fact that reference and
>>> value semantics are fundamentally different and make design choices
>>> (including languag

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

[David Waite via swift-evolution]

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

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

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

-DW


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution