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

[Dave Abrahams via swift-evolution]

on Sun May 15 2016, Tyler Fleming Cloutier  wrote:

> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution 
>  wrote:
>
> on Mon May 09 2016, Matthew Johnson  wrote:
>
> On May 8, 2016, at 1:51 AM, Dave Abrahams  
> wrote:
>
> on Sat May 07 2016, Andrew Trick  wrote:
>
>   On May 7, 2016, at 2:04 PM, Dave Abrahams 
>  wrote:
>
>   2. Value types are not "pure" values if any part of the 
> aggregate
>   contains a
>   reference whose type does not have value semantics. 
>
>   Then Array is not a “pure” value (the buffer contained 
> in an
>   Array is a mutable reference type that on its own, 
> definitely does
>   *not* have value semantics). I don't think this is what you 
> intend, and
>   it indicates that you need to keep working on your 
> definition.
>
> It sounds like you’re changing the definition of value 
> semantics to make it
> impossible to define PureValue. 
>
> Not on purpose.
>
> Does Array have value semantics then only if T also has 
> value
> semantics?
>
> This is a great question; I had to rewrite my response four times.
>
> In my world, an Array always has value semantics if you 
> respect the
> boundaries of element values as defined by ==.  That means that 
> if T is
> a mutable reference type, you're not looking through references, 
> because
> == is equivalent to ===.
>
> Therefore, for almost any interesting SomeConstraint that doesn't 
> refine
> ValueSemantics, then
>
> Array
>
> only has value semantics if T has value semantics, since 
> SomeConstraint
> presumably uses aspects of T other than reference identity.  
>
> The claim has been made that Array always has value semantics,
> implying that the array value’s boundary ends at the boundary 
> of it’s
> element values.
>
> Yes, an array value ends at the boundary of its elements' values.
>
> That fact is what allows the compiler to ignore mutation of 
> the
> buffer.
>
> I don't know what you mean here.
>
> It's perfectly clear that Array is a PureValue iff T is a 
> PureValue.
> PureValue is nothing more than transitive value semantics.
>
> You're almost there.  “Transitive” implies that you are going to 
> look at
> the parts of a type to see if they are also PureValue's.  So 
> which parts
> of the Array struct does one look at, and why?  Just tell me the
> procedure for determining whether a type is a PureValue.
>
> We look at the observable parts.  
>
> That begs the question.  The “parts” of an Array are the observable
> features that are considered by equality.
>
> We do not look at unobservable parts because we want flexibility to
> use things like CoW, shared immutable references, etc in our
> implementation.
>
> IMO the important thing when it comes to functional purity is not what
> you *can* observe, but what you *do* observe.
>
> Can you share your definition of value semantics?  
>
> Explaining it well and in sufficient detail for this discussion takes
> some doing, but I think John Lakos and I share an understanding of value
> semantics and he has a really detailed explanation in
> https://www.youtube.com/watch?v=W3xI1HJUy7Q and
> https://www.youtube.com/watch?v=0EvSxHxFknM.  He uses C++ in places,
> but it's not particularly advanced, and the fundamental ideas apply just
> as well to Swift.
>
> Super interesting talk! 
>
> But consider: isn't a single value type able to represent *multiple*
> ethereal types?

“ethereal?”  Does he really use that term?  I don't know what it means.

>
> std::vector is a good example. What are the salient attributes of this
> type? In the talk John says that
>
> 1. the size is
> 2. the values in the vector are
> 3. the capacity, however *is not*

Yup, just like Array.  Thus the equality test for arrays ignores
capacity.

> in which case std::vector would be an approximation of an ethereal
> type which has a list of values, and the capacity is just an artifact
> of the approximation. But you could also imagine an ethereal type
> which *does* depend of the capacity of the object, and std::vector
> unwittingly approximates that type too! In this case someone,
> unfamiliar with the implementation might use it under the assumption
> that capacity *is* part of the ethereal type and by extension the
> equality of std::vector.
>
> John avoids the problem by saying that this must specified in the
> documentation.

Yes.

> I tend to see this as breakin

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

[Tyler Fleming Cloutier via swift-evolution]

> On May 15, 2016, at 11:17 PM, Tyler Fleming Cloutier via swift-evolution 
>  wrote:
> 
>> 
>> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> on Mon May 09 2016, Matthew Johnson > > wrote:
>> 
 On May 8, 2016, at 1:51 AM, Dave Abrahams >>> > wrote:
 
 
 on Sat May 07 2016, Andrew Trick >>> > wrote:
 
>>> 
>   On May 7, 2016, at 2:04 PM, Dave Abrahams  > wrote:
> 
>   2. Value types are not "pure" values if any part of the aggregate
>   contains a
>   reference whose type does not have value semantics. 
> 
>   Then Array is not a “pure” value (the buffer contained in an
>   Array is a mutable reference type that on its own, definitely does
>   *not* have value semantics). I don't think this is what you intend, and
>   it indicates that you need to keep working on your definition.
> 
> It sounds like you’re changing the definition of value semantics to make 
> it
> impossible to define PureValue. 
 
 Not on purpose.
 
> Does Array have value semantics then only if T also has value
> semantics?
 
 This is a great question; I had to rewrite my response four times.
 
 In my world, an Array always has value semantics if you respect the
 boundaries of element values as defined by ==.  That means that if T is
 a mutable reference type, you're not looking through references, because
 == is equivalent to ===.
 
 Therefore, for almost any interesting SomeConstraint that doesn't refine
 ValueSemantics, then
 
 Array
 
 only has value semantics if T has value semantics, since SomeConstraint
 presumably uses aspects of T other than reference identity.  
 
> The claim has been made that Array always has value semantics,
> implying that the array value’s boundary ends at the boundary of it’s
> element values.
 
 Yes, an array value ends at the boundary of its elements' values.
 
> That fact is what allows the compiler to ignore mutation of the
> buffer.
 
 I don't know what you mean here.
 
> It's perfectly clear that Array is a PureValue iff T is a PureValue.
> PureValue is nothing more than transitive value semantics.
 
 You're almost there.  “Transitive” implies that you are going to look at
 the parts of a type to see if they are also PureValue's.  So which parts
 of the Array struct does one look at, and why?  Just tell me the
 procedure for determining whether a type is a PureValue.
>>> 
>>> We look at the observable parts.  
>> 
>> That begs the question.  The “parts” of an Array are the observable
>> features that are considered by equality.
>> 
>>> We do not look at unobservable parts because we want flexibility to
>>> use things like CoW, shared immutable references, etc in our
>>> implementation.
>> 
>> IMO the important thing when it comes to functional purity is not what
>> you *can* observe, but what you *do* observe.
>> 
>>> Can you share your definition of value semantics?  
>> 
>> Explaining it well and in sufficient detail for this discussion takes
>> some doing, but I think John Lakos and I share an understanding of value
>> semantics and he has a really detailed explanation in
>> https://www.youtube.com/watch?v=W3xI1HJUy7Q 
>>  and
>> https://www.youtube.com/watch?v=0EvSxHxFknM 
>> .  He uses C++ in places,
>> but it's not particularly advanced, and the fundamental ideas apply just
>> as well to Swift.
>> 
> 
> Super interesting talk! 
> 
> But consider: isn't a single value type able to represent *multiple* ethereal 
> types?
> 
> std::vector is a good example. What are the salient attributes of this type? 
> In the talk John says that
> 
> 1. the size is
> 2. the values in the vector are
> 3. the capacity, however *is not*
> 
> in which case std::vector would be an approximation of an ethereal type which 
> has a list of values, and the capacity is just an artifact of the 
> approximation. But you could also imagine an ethereal type which *does* 
> depend of the capacity of the object, and std::vector unwittingly 
> approximates that type too! In this case someone, unfamiliar with the 
> implementation might use it under the assumption that capacity *is* part of 
> the ethereal type and by extension the equality of std::vector. 
> 
> John avoids the problem by saying that this must specified in the 
> documentation.
> 
> I tend to see this as breaking encapsulation since you need to know the 
> implementation of the equality operator to be able to determine if a public 
> property, the capacity, is part of the ethereal type. It’s not always the 
> case that you have access to 

Re: [swift-evolution] [Pitch] Add toplevel keyword for protocols

[Patrick Pijnappel via swift-evolution]

>
> Hi Patrick,
> FYI, we’re very likely to remove this special behavior for operators, by
> making operator requirements only find operators declared in a conforming
> type.  This would eliminate the special case for operators that exists now,
> and has other advantages as well.  Check out this proposal for more
> information:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md


Thanks, hadn't seen that one yet! Looks like a good solution.

On Sun, May 15, 2016 at 7:10 AM, Chris Lattner  wrote:

>
> On May 13, 2016, at 12:12 AM, Patrick Pijnappel via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> For some protocols we'd like to require top-level (free) functions, e.g.
> for many math functions such as abs() or sin(). We already do this
> implicitly for operators.
>
>
> Hi Patrick,
>
> FYI, we’re very likely to remove this special behavior for operators, by
> making operator requirements only find operators declared in a conforming
> type.  This would eliminate the special case for operators that exists now,
> and has other advantages as well.  Check out this proposal for more
> information:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md
>
> -Chris
>
>
> *Proposal*
> Allow top-level function/property requirements in protocols, e.g.:
>
> public protocol AbsoluteValuable : SignedNumber { /// Returns the
> absolute value of `x`. @warn_unused_result toplevel func abs(_ x: Self) ->
> Self }
>
> We'd probably want to require this for operators. This also opens up
> syntax if we ever get dynamically dispatched operators.
>
> public protocol SignedNumber : Comparable, IntegerLiteralConvertible { ///
> Returns the result of negating `x`. @warn_unused_result toplevel prefix
> func - (x: Self) -> Self }
>
> Currently this is done using the combination of a static method and a
> top-level generic function on that protocol. As I understand that approach
> does have some benefits in terms of type-checker performance, though I'm
> not sure whether that is likely to stay relevant in the future.
>
> *Advantages*
>
>- Cleaner than current approach (esp. floating point types have tons
>of top-level functions)
>- Makes operators less of a special case
>- Opens up syntax for member operators
>- Could also apply to top-level properties (esp. useful if we get
>generic properties, for e.g. π<...>)
>
> ___
> 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?

[Tyler Fleming Cloutier via swift-evolution]

> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon May 09 2016, Matthew Johnson  > wrote:
> 
>>> On May 8, 2016, at 1:51 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Sat May 07 2016, Andrew Trick  wrote:
>>> 
>> 
   On May 7, 2016, at 2:04 PM, Dave Abrahams  wrote:
 
   2. Value types are not "pure" values if any part of the aggregate
   contains a
   reference whose type does not have value semantics. 
 
   Then Array is not a “pure” value (the buffer contained in an
   Array is a mutable reference type that on its own, definitely does
   *not* have value semantics). I don't think this is what you intend, and
   it indicates that you need to keep working on your definition.
 
 It sounds like you’re changing the definition of value semantics to make it
 impossible to define PureValue. 
>>> 
>>> Not on purpose.
>>> 
 Does Array have value semantics then only if T also has value
 semantics?
>>> 
>>> This is a great question; I had to rewrite my response four times.
>>> 
>>> In my world, an Array always has value semantics if you respect the
>>> boundaries of element values as defined by ==.  That means that if T is
>>> a mutable reference type, you're not looking through references, because
>>> == is equivalent to ===.
>>> 
>>> Therefore, for almost any interesting SomeConstraint that doesn't refine
>>> ValueSemantics, then
>>> 
>>> Array
>>> 
>>> only has value semantics if T has value semantics, since SomeConstraint
>>> presumably uses aspects of T other than reference identity.  
>>> 
 The claim has been made that Array always has value semantics,
 implying that the array value’s boundary ends at the boundary of it’s
 element values.
>>> 
>>> Yes, an array value ends at the boundary of its elements' values.
>>> 
 That fact is what allows the compiler to ignore mutation of the
 buffer.
>>> 
>>> I don't know what you mean here.
>>> 
 It's perfectly clear that Array is a PureValue iff T is a PureValue.
 PureValue is nothing more than transitive value semantics.
>>> 
>>> You're almost there.  “Transitive” implies that you are going to look at
>>> the parts of a type to see if they are also PureValue's.  So which parts
>>> of the Array struct does one look at, and why?  Just tell me the
>>> procedure for determining whether a type is a PureValue.
>> 
>> We look at the observable parts.  
> 
> That begs the question.  The “parts” of an Array are the observable
> features that are considered by equality.
> 
>> We do not look at unobservable parts because we want flexibility to
>> use things like CoW, shared immutable references, etc in our
>> implementation.
> 
> IMO the important thing when it comes to functional purity is not what
> you *can* observe, but what you *do* observe.
> 
>> Can you share your definition of value semantics?  
> 
> Explaining it well and in sufficient detail for this discussion takes
> some doing, but I think John Lakos and I share an understanding of value
> semantics and he has a really detailed explanation in
> https://www.youtube.com/watch?v=W3xI1HJUy7Q 
>  and
> https://www.youtube.com/watch?v=0EvSxHxFknM 
> .  He uses C++ in places,
> but it's not particularly advanced, and the fundamental ideas apply just
> as well to Swift.
> 

Super interesting talk! 

But consider: isn't a single value type able to represent *multiple* ethereal 
types?

std::vector is a good example. What are the salient attributes of this type? In 
the talk John says that

1. the size is
2. the values in the vector are
3. the capacity, however *is not*

in which case std::vector would be an approximation of an ethereal type which 
has a list of values, and the capacity is just an artifact of the 
approximation. But you could also imagine an ethereal type which *does* depend 
of the capacity of the object, and std::vector unwittingly approximates that 
type too! In this case someone, unfamiliar with the implementation might use it 
under the assumption that capacity *is* part of the ethereal type and by 
extension the equality of std::vector. 

John avoids the problem by saying that this must specified in the documentation.

I tend to see this as breaking encapsulation since you need to know the 
implementation of the equality operator to be able to determine if a public 
property, the capacity, is part of the ethereal type. It’s not always the case 
that you have access to either the documentation or the implementation.

This implies, therefore, that if salient attributes *define* the immutability 
of the value type, then the public interface is not guaranteed to be immutable, 
since it is allowed to include non-salient attributes. For example, a vector’s 
capacity could change at any time, by virtue of it being stored via a reference.

What I am s

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

[Pyry Jahkola via swift-evolution]

> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> I'm actually tempted to suggest that a conformance should be *mandatory* and 
> you should have to specify `Any` if you don't have anything more specific to 
> say about the generic parameter:
> 
>   func map(@noescape transform: (Element) throws -> T) rethrows 
> -> [T]

That's a good idea indeed if we ever intend to have other kinds of generic 
arguments (in particular, constant values like `length: Int`).

Even so, I wouldn't want to prohibit adding more protocol constraints in the 
where clause even if you can introduce all constaints of `T` at once as `T: 
protocol`.

— Pyry

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

[swift-evolution] StringInterpolationConvertible and StringLiteralConvertible inheritance

[Ben Rimmington via swift-evolution]

StringInterpolationConvertible inheritance of StringLiteralConvertible would
allow "static-string" and \(string-expression) segments to be differentiated.

/// For example, `"\(paragraph)" as HTML` would invoke:
///
/// HTML.init(stringInterpolation:
/// HTML.init(stringLiteral: ""),
/// HTML.init(stringInterpolationSegment: paragraph),
/// HTML.init(stringLiteral: "")
/// )
///
/// The conforming HTML type would be able to escape "<" and ">" characters
/// in the \(paragraph) string, without affecting the "" and "" tags.
///
protocol StringInterpolationConvertible : StringLiteralConvertible {
init(stringInterpolation: Self...)
init(stringInterpolationSegment: T)
}

I also wonder why the following inheritance is needed:

* StringLiteralConvertible : ExtendedGraphemeClusterLiteralConvertible
* ExtendedGraphemeClusterLiteralConvertible : UnicodeScalarLiteralConvertible

-- Ben


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

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Andru Felipe Zuniga via swift-evolution]

It would be useful for clarification of a computed property being constant in 
extensions. For example:

extension SKSpriteNode {
static let type: String {
return “Sprite”
}
}

Andru



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

Re: [swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Ben Rimmington via swift-evolution]

Re: UPDATED APPROACH


## Initializable

+1 although the existing -Convertible suffix isn't bad.

(ExtendedGraphemeClusterLiteral could also be renamed to CharacterLiteral).

## Representable

+1 for the Custom[Debug]StringRepresentable protocols.

(The related Streamable and OutputStream[able] names are also problematic).

-- Ben


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

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

[Patrick Smith via swift-evolution]

I tend to agree with Jon Shier, Karl Wagner, Nicola Salmoria, and Tony 
Allevato. I think moving `where` to the end hinders comprehension. The extra 
constraint abilities that Nicola brought up look interesting.


> On 15 May 2016, at 1:52 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> On 2016-05-10 18:51:29 +, Chris Lattner via swift-evolution said:
> 
>> Hello Swift community,
>> The review of "SE-0081: Move where clause to end of declaration" begins now 
>> and runs through May 16. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
>>  Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> What goes into a review?
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>>  * What is your evaluation of the proposal?
> 
> -1. My thoughts essentially mirror those of Jon Shier, Karl Wagner, and 
> Nicola Salmoria.
> 
> To me, this makes declarations with complex sets of constraints much harder 
> to read, because I have to hunt them down instead of finding them all in one 
> place. Under this proposal, the longer an argument list gets, the further 
> separated the constraints are from the type parameters that use them.
> 
> This solution also obfuscates function definitions. Having the function's 
> return type be the very last thing in the header line is has very nice 
> readability benefit, and this proposal takes that away by sandwiching the 
> return type awkwardly in the middle.
> 
> The admission that some constraints should be allowed inside the angle 
> brackets (conformance constraints) while moving others (associated type 
> constraints) out introduces inconsistency in the language and seems like an 
> incomplete fix. From a teaching point of view, I would find it more difficult 
> to explain to users of the language "constraints that look like *this* go 
> here, but constraints that look like *that* go way over there". The current 
> model of "all generic constraints go between < and >" is clean and simple.
> 
> Lastly, from a bit of a pedantic point of view, moving the where-clause to 
> the end of a function declaration makes it look like the function is 
> satisfying some constraints, when it's actually the generic type parameters 
> that are satisfying them. In that sense, it's better to keep them closer 
> together.
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes, but not in this fashion. I agree with some of the other sentiment that 
> there should be better ways of satisfying complex constraint sets (through 
> generic typealiases or something else) to clean them up, but moving the 
> where-clause creates more readability problems than it solves.
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> I don't believe so; it adds inconsistency rather than removes it.
> 
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> No languages that allow generics to be expressed so richly as Swift's.
> 
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Read the proposal and followed the mailing list threads.
> 
>> More information about the Swift evolution process is available at
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> -Chris Lattner
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Goffredo Marocchi via swift-evolution]

Makes sense, I would not mind the mandatory conformance actually.

Sent from my iPhone

On 15 May 2016, at 23:45, Brent Royal-Gordon  wrote:

>> Being able to let the developer decide how to place relevant type 
>> information with the freedom of being able to keep some/all/none type 
>> information local and some/none/all extra information moved to the end of 
>> the declaration.
> 
> To be clear, I do think it makes sense to move *all* `where` clauses to the 
> end of the parameter list, not allow them both within the angle brackets and 
> at the end of the definition. And I'm not convinced it makes sense to support 
> moving all conformance information to the `where` clause, either. A generic 
> parameter list like `` is vacuous; when you're dealing with something 
> like this:
> 
>public func transcode
> UnicodeCodec>
>(_ input: Input, from inputEncoding: InputEncoding.Type, to 
> outputEncoding: OutputEncoding.Type, stoppingOnError stopOnError: Bool, 
> sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void) 
> -> Bool
>where InputEncoding.CodeUnit == Input.Element
> 
> The detail in the `where` clause really is of secondary importance, 
> especially compared to how much syntax it takes to specify, while this:
> 
>public func transcode
>(_ input: Input, from 
> inputEncoding: InputEncoding.Type, to outputEncoding: OutputEncoding.Type, 
> stoppingOnError stopOnError: Bool, sendingOutputTo processCodeUnit: @noescape 
> (OutputEncoding.CodeUnit) -> Void) -> Bool
>where Input: IteratorProtocol, InputEncoding: UnicodeCodec, 
> OutputEncoding: UnicodeCodec, InputEncoding.CodeUnit == Input.Element
> 
> Leaves far too much unspecified until the end.
> 
> I'm actually tempted to suggest that a conformance should be *mandatory* and 
> you should have to specify `Any` if you don't have anything more specific to 
> say about the generic parameter:
> 
>func map(@noescape transform: (Element) throws -> T) rethrows -> 
> [T]
> 
> That would penalize the "leave everything until the end" style without 
> actually introducing any arbitrary rules forbidding it.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> Being able to let the developer decide how to place relevant type information 
> with the freedom of being able to keep some/all/none type information local 
> and some/none/all extra information moved to the end of the declaration.

To be clear, I do think it makes sense to move *all* `where` clauses to the end 
of the parameter list, not allow them both within the angle brackets and at the 
end of the definition. And I'm not convinced it makes sense to support moving 
all conformance information to the `where` clause, either. A generic parameter 
list like `` is vacuous; when you're dealing with something like this:

public func transcode

(_ input: Input, from inputEncoding: InputEncoding.Type, to 
outputEncoding: OutputEncoding.Type, stoppingOnError stopOnError: Bool, 
sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void) 
-> Bool
where InputEncoding.CodeUnit == Input.Element

The detail in the `where` clause really is of secondary importance, especially 
compared to how much syntax it takes to specify, while this:

public func transcode
(_ input: Input, from 
inputEncoding: InputEncoding.Type, to outputEncoding: OutputEncoding.Type, 
stoppingOnError stopOnError: Bool, sendingOutputTo processCodeUnit: @noescape 
(OutputEncoding.CodeUnit) -> Void) -> Bool
where Input: IteratorProtocol, InputEncoding: UnicodeCodec, 
OutputEncoding: UnicodeCodec, InputEncoding.CodeUnit == Input.Element

Leaves far too much unspecified until the end.

I'm actually tempted to suggest that a conformance should be *mandatory* and 
you should have to specify `Any` if you don't have anything more specific to 
say about the generic parameter:

func map(@noescape transform: (Element) throws -> T) rethrows 
-> [T]

That would penalize the "leave everything until the end" style without actually 
introducing any arbitrary rules forbidding it.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Removing "_ in" from empty closures

[Dave Abrahams via swift-evolution]

on Fri May 13 2016, Joe Groff  wrote:

>> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution 
>>  wrote:
>> 
>> Currently if a closure takes a value, it requires "_ in" to note
>> that the value is ignored. This makes sense in many cases, but
>> creates a bit of a mess in the case of an empty, void-returning
>
>> closure:
>> 
>> doThing(withCompletion: { _ in })
>> 
>> I'd like to suggest that the compiler promote the empty closure
>> literal {} to any void-returning closure type so that this could be
>> written:
>> 
>> doThing(withCompletion: {})
>> 
>> This encourages the use of empty closures over optional closures,
>> which I think is open for debate. In general I try to avoid
>> optionals when they can be precisely replaced with a non-optional
>> value. Furthermore, most Cocoa completion handlers are not optional.
>> 
>> The alternative is to not do this, but encourage that any closure
>> that could reasonably be empty should in fact be optional. I would
>> then want Cocoa functions with void-returning closures to be
>> imported as optionals to avoid "{ _ in }".
>
> +1. In general, I think we should allow implicit arguments, without
> requiring the closure to use all the implicit $n variables like we do
> today. These should all be valid:
>
> let _: () -> () = {}
> let _: (Int) -> () = {}
> let _: (Int, Int) -> Int = { 5 }
> let _: (Int, Int) -> Int = { $0 }
> let _: (Int, Int) -> Int = { $1 }

+1

-- 
-Dave

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

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

[Dave Abrahams via swift-evolution]

on Fri May 13 2016, Matthew Johnson  wrote:

> Sent from my iPad
>
>> On May 13, 2016, at 9:12 AM, Dave Abrahams  wrote:
>> 
>> 
>>> on Mon May 09 2016, Matthew Johnson  wrote:
>>> 
>>>My claim is that substituting the constraint of “it has value
>>>semantics,” while presumably looser than the PureValue constraint, would
>>>not compromise the correctness of your view controller, so not only is
>>>the meaning of PureValue hard to define, but it doesn't buy you
>>>anything.  If you want to refute that, just show me the code.
>>> 
>>>This is not an algorithmic use but is still perfectly valid IMO.
>>> 
>>>If the properties of PureValue matter to your view controller, there's
>>>an algorithm somewhere that depends on those properties for its
>>>correctness.
>>> 
>>> In many cases it may just be view configuration that depends on those
>>> properties.  I suppose you can call view configuration code an
>>> algorithm but I think that would fall outside of common usage.
>> 
>> It's an algorithm, or if the configuration is declarative, there's an
>> algorithm that manipulates it.  That said, I still don't have a concrete
>> example of how view configuration can depend on these properties.
>
> The algorithm might just be "copy x bit of data to y view property,
> etc".  That is so trivial that it feels like a stretch to call it an
> algorithm.

Algorithms can be trivial.

> That "algorithm" doesn't depend on this property because it executes
> at a single point in time.  However, a view controller might depend on
> that property in order to render properly across time (for example,
> configuring cells as they scroll on and off screen).

The example is too abstract for me to understand.

Let me put this differently: I recognize that your concept of
“PureValue” may be a *sufficient* condition for some generic
algorithm/component to work, but it is never a *necessary* condition,
because genericity (or use of a superclass or protocol type) erases
details of the actual types involved from the point of view of the
algorithm/component.  It doesn't matter if your type contains a class
reference if it has value semantic properties.  My claim is that
PureValue is an overly-restrictive constraint that makes many things
less useful than they should be.

> This property allows us to separate values from non-local mutation and
> make such separation a requirement.  Rather than observing mutations
> of objects with KVO, etc we might prefer to observe something that
> provides a new aggregate value instead, while requiring the entire
> aggregate value itself to be (observably) immutable at all times
> (because we stored it with a let property locally).  This can make it
> easier to reason about correct behavior of your code.  But it doesn't
> work unless all visible parts of the aggregate are immutable.
>
>  If you're not familiar with Elm, Redux, etc it might be worth taking
>  a look.  

That's a pretty broad link.  At which parts do you think I should look?

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

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

[Dave Abrahams via swift-evolution]

on Fri May 13 2016, Matthew Johnson  wrote:

> Sent from my iPad
>
>> On May 13, 2016, at 9:19 AM, Dave Abrahams  wrote:
>> 
>> 
>>> on Mon May 09 2016, Matthew Johnson  wrote:
>>> 
>>>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.
>>> 
>>> It’s not too awful but it does expose implementation details.  
>> 
>> How?  All the changes are under “private”
>
> Sorry, I didn't notice private.  Probably because I am thinking of model 
> types which expose their stored properties.
>
>>> If we’re going to hide the implementation details maybe it’s worth
>>> taking advantage of the type by making the props var and using CoW.
>>> 
>>> What do you think about a proposal to enhance “indirect” for value
>>> types and / or instances of them.  I can think of a few approaches to
>>> this that we could consider.  I would be much more comfortable with
>>> what you want to do if we tackle that as well.
>> 
>> It's a good idea that can help to make CoW easy to implement; I have
>> advocated for it (not in public) in the past.  
>
> Glad to hear this.  Maybe in Swift 4?  (I know it's too early to say)
>
>> People should be aware
>> that the resulting automatic CoW will be suboptimal in many cases,
>> because when you discover you need new storage it's usually better to
>> build a new value than to copy the old one and overwrite it.
>
> How big a difference does that usually make, especially when compared
> to the reasons you would use indirect in the first place?  

Usually a big difference.

> Wouldn't the compiler be able to do this in the automatic
> implementation in some cases

Not in any interesting cases I know of.  If you're inserting into an
array and you discover you need new storage because there is more than
one reference, starting by copying can double the cost of the insertion
(on a large array when memory allocation is fast).

> (such as writing to a stored var)?

I don't know what you mean here.

> Would it be possible to design indirect value types in a way that
> allows a transition to manual control of CoW without breaking calling
> code if that becomes necessary?

Sure, anything is possible in design, and in a feature like this I would
of course want that capability.  It isn't the right time (for me) to try
to figure it all out though :-)

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

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

[Dave Abrahams via swift-evolution]

on Mon May 09 2016, Matthew Johnson  wrote:

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

That begs the question.  The “parts” of an Array are the observable
features that are considered by equality.

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

IMO the important thing when it comes to functional purity is not what
you *can* observe, but what you *do* observe.

> Can you share your definition of value semantics?  

Explaining it well and in sufficient detail for this discussion takes
some doing, but I think John Lakos and I share an understanding of value
semantics and he has a really detailed explanation in
https://www.youtube.com/watch?v=W3xI1HJUy7Q and
https://www.youtube.com/watch?v=0EvSxHxFknM.  He uses C++ in places,
but it's not particularly advanced, and the fundamental ideas apply just
as well to Swift.

> It may be helpful
> if we start there and refine your definition to exclude impure value
> types like Array.
>
> In the meantime I’ll take another shot:
>
> 1. Scalars are pure values.
>
> 2. Any aggregate type with value semantics is a pure value iff all
>observable parts of the aggregate are pure values.


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

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

[Dave Abrahams via swift-evolution]

on Fri May 13 2016, Nate Cook  wrote:

>>> On May 13, 2016, at 9:36 AM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> on Mon May 09 2016, Nate Cook  wrote:
>>> 
>>> Yet another alternative would be to drop Set and Dictionary down a
>>> level to a FiniteSequence protocol in between Sequence and
>>> Collection. Basically none of the index-based collection APIs
>>> (i.e. everything except `count` and `isEmpty`) make sense on sets and
>>> dictionaries.
>> 
>> Strongly disagreed.  Any read-only operation that makes sense on a
>> bidirectional collection makes sense on these data structures.
>
> I don't see how the methods that impose meaning on the order of a set
> are useful. What does mySet.prefix(upTo: i) mean when I have no
> control or dependable way of knowing which elements lie between
> startIndex and i? mySet.first is useful, but it's meaning is more like
> NSSet's anyObject.

If you give me a random collection of Ts, I may want to find the index
of the first element that satisfies some predicate.  Then I may want to
process the prefix of elements that don't satisfy that predicate, and
repeat.

In general, many algorithms that operate on a collection place no
requirements on the semantic relationship and/or ordering of the
elements, and such algorithms can still be useful on Sets.  Use your
imagination and you'll see more of them, e.g. find the index of the
maximum element in the set (so that you can remove it).

>>> index(where:) was marginally useful with dictionaries, but now that
>>> Sequence is getting first(where:), née find(...), even that isn't
>>> necessary.
>> 
>>   s.remove(at: s.index(where: { $0 < 1 }))
>
> Since Set's remove(at:) method is type-specific, it would need to be
> rewritten as remove(where:). 

? What does “type-specific” mean and why do you say so?

If we don't have a remove(at:) method for Set, that's a bug.  Whether we
need a RangeRemovableCollection that is refined by
RangeReplaceableCollection is an interesting question.

> This example is kind of my point, though - it removes the first
> element less than 1, but only one such element, and there's no telling
> which. That's not an operation I've ever needed to perform on a set.
>
> To clarify, I don't think the current system is hurting Set and
> Dictionary in any way. It's simply providing them with methods that
> aren't very useful for that particular data structure.

It's true that it's harder to find algorithms that are *very likely* to
be useful on collections whose ordering is not controlled, but that
doesn't mean those collections shouldn't satisfy the Collection
protocol.  Even parallelization of trivial operations such as “find the
minimum element” requires the the fundamental properties of Collection.

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

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

[Dave Abrahams via swift-evolution]

on Fri May 13 2016, Joe Groff  wrote:

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

Thanks for clarifying.

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

Re: [swift-evolution] Removing "_ in" from empty closures

[Erica Sadun via swift-evolution]

> On May 14, 2016, at 11:16 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution 
>  wrote:
>>> This encourages the use of empty closures over optional closures, which I 
>>> think is open for debate. In general I try to avoid optionals when they can 
>>> be precisely replaced with a non-optional value. Furthermore, most Cocoa 
>>> completion handlers are not optional.
>>> 
>>> The alternative is to not do this, but encourage that any closure that 
>>> could reasonably be empty should in fact be optional. I would then want 
>>> Cocoa functions with void-returning closures to be imported as optionals to 
>>> avoid "{ _ in }".
>> 
>> +1. In general, I think we should allow implicit arguments, without 
>> requiring the closure to use all the implicit $n variables like we do today. 
>> These should all be valid:
>> 
>> let _: () -> () = {}
>> let _: (Int) -> () = {}
>> let _: (Int, Int) -> Int = { 5 }
>> let _: (Int, Int) -> Int = { $0 }
>> let _: (Int, Int) -> Int = { $1 }
> 
> I agree, but I consider this to be an obvious bug in the compiler.  I don’t 
> think it requires a proposal.
> 
> Unfortunately it is non-trivial to fix…


https://bugs.swift.org/browse/SR-1528

-- E

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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Vladimir.S via swift-evolution]

Tino, I believe you can start just with [Draft]... thread where you can 
present the draft of your proposal. Then, after you'll get opinions and 
after the draft will be polished, you can form an 'official' proposal.


For now I didn't hear if someone else wanted to create that proposal. So I 
don't see any barrier for you to do this(if you want).


As for proposal itself. Yes, I also think almost all of SE-0084 goals could 
be archived in your proposal.
But, personally I believe new proposal should introduce newlines as 
separators for any comma-separated list, not limited by funcs/typles but 
also array/dicts/generic type list etc. If something will be hard/imposible 
to implement - core team can accept the proposal with some exceptions after 
the review.


On 15.05.2016 13:18, Tino Heth wrote:



Tino, would you like to form an 'official' proposal for this(newlines
as separators) feature? As I can see, there is a much support in
community for this idea, but no one said yet he/she will create a
proposal for this.(or I just missed this)

I feel honored, but I guess there are others (native speaker, closer
relation to the core team...) who are better suited than me... On the
other hand, I lack fear of seeing a proposal rejected ;-), so as long as
deeper thinking doesn't reveal any downsides, I don't mind spending some
hours and putting my name on the pull request. Afaics, there are no
plans to change SE-0084 to at least add "making commas optional if
followed by a newline" as an alternative, so the first step would be a
separate thread ("Newlines as item separators in lists"?) — but as all
examples in the proposal use commas followed by newlines, I think all of
its goals could be archived


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

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

[Maximilian Hünenberger via swift-evolution]

I brought these up because the current implementation produces an error in 
these cases. You have to insert additional min/max operations.

> Am 15.05.2016 um 16:38 schrieb Luis Henrique B. Sousa :
> 
> Exactly, the idea is to return an empty array just like other languages do. 
> (e.g. python)
> 
> - Luis
> 
>> On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution 
>>  wrote:
>>> On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote:
>>> One point which should be discussed is the following behaviour:
>>> 
>>> let array = [0]
>>> // ranges are completely out of bounds and produce an error
>>> array[clamping: 1...2] // error
>>> array[clamping: -2...-1] // error
>>> 
>>> Should a range which has no intersection with the indices of the collection
>>> produce an error or just clamp to 0..<0 respectively endIndex..> 
>> I expect it will returns [] i.e. empty array, as no elements with 
>> 1...2(-2..-1) indexes in the array. I understand `clamping` similar as 
>> 'bounded','in these bounds'. And as soon as [0,1,2,3,4][clamping:2...10] 
>> will silently move the right position to allowed index(4), and 
>> [0,1,2,3,4][clamping:-2...0]  will move left position to 0, I expect that in 
>> [0][clamping: 1...2] will try to move both limits to allowed, and as no 
>> intersection - silently return empty array.
>> 
>>> 
>>> Best regards
>>> Maximilian
>>> 
>>> Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution
>>> mailto:swift-evolution@swift.org>>:
>>> 
 It seems that there is a consensus that this proposal might be a good
 addition to the standard library. All comments on this thread in the past
 few weeks were related to naming, not around the behaviour or validity of
 the proposed methods. So I will submit this proposal for review very soon
 assuming that nobody else has strong arguments against it. :-)
 
 Proposal: 
 https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
 
 If you have any corrections or suggestions to the proposal text itself,
 please comment on this gist:
 https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
 (or pull request to my repo)
 
 Regards,
 
 - Luis
 
 On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa
 mailto:lshso...@gmail.com>> wrote:
 
 Please let me know if you have more suggestions or corrections on
 this proposal.
 I'm tempted to submit it for review. :-)
 
 - Luis
 
 On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa
 mailto:lshso...@gmail.com>> wrote:
 
 It sounds good, thanks for you suggestions @Vladimir, @Patrick
 and @Brent.
 
 I've just updated the proposal:
 
 https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
 
 - Luis
 
 On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution
 mailto:swift-evolution@swift.org>> 
 wrote:
 
 Yes, I feel like 'within' is much better than 'bounded'.
 
 How about such changes in proposal:
 
 a[bounded: -1 ..< 5]  -->  a[within: -1 ..< 5]  (or a[inside:
 -1 ..< 5] )
 
 a[optional: 0 ..< 5]  -->  a[checking: 0 ..< 5]
 a[optional: 5]-->  a[checking: 5]
 
 ?
 
 On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:
 
 I like the idea of the of the bounded subscript, however
 the optional one I
 feel could be used for clumsy code.
 
 .first and .last have value, but once you start stepping
 several arbitrary
 indices in, then that code is likely fragile?
 
 
 I can think of ‘within’, ‘inside’ and ‘intersecting’ as
 alternative names
 for ‘bounded’ that attempt to explain what is going on:
 
 let a = [1, 2, 3]
 
 a[within: 0 ..< 5] // [1, 2, 3]
 a[inside: 0 ..< 5] // [1, 2, 3]
 a[intersecting: 0 ..< 5] // [1, 2, 3]
 
 
 On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa
 via swift-evolution
 >>> 
 >> wrote:
 
 As we have discussed throughout this thread, the
 initial proposal was
 modified to include alternative

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

[Luis Henrique B. Sousa via swift-evolution]

Exactly, the idea is to return an empty array just like other languages do.
(e.g. python)

- Luis

On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote:
>
>> One point which should be discussed is the following behaviour:
>>
>> let array = [0]
>> // ranges are completely out of bounds and produce an error
>> array[clamping: 1...2] // error
>> array[clamping: -2...-1] // error
>>
>> Should a range which has no intersection with the indices of the
>> collection
>> produce an error or just clamp to 0..<0 respectively endIndex..>
>
> I expect it will returns [] i.e. empty array, as no elements with
> 1...2(-2..-1) indexes in the array. I understand `clamping` similar as
> 'bounded','in these bounds'. And as soon as [0,1,2,3,4][clamping:2...10]
> will silently move the right position to allowed index(4), and
> [0,1,2,3,4][clamping:-2...0]  will move left position to 0, I expect that
> in [0][clamping: 1...2] will try to move both limits to allowed, and as no
> intersection - silently return empty array.
>
>
>> Best regards
>> Maximilian
>>
>> Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution
>> mailto:swift-evolution@swift.org>>:
>>
>> It seems that there is a consensus that this proposal might be a good
>>> addition to the standard library. All comments on this thread in the past
>>> few weeks were related to naming, not around the behaviour or validity of
>>> the proposed methods. So I will submit this proposal for review very soon
>>> assuming that nobody else has strong arguments against it. :-)
>>>
>>> Proposal:
>>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
>>>
>>> If you have any corrections or suggestions to the proposal text itself,
>>> please comment on this gist:
>>> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
>>> (or pull request to my repo)
>>>
>>> Regards,
>>>
>>> - Luis
>>>
>>> On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa
>>> mailto:lshso...@gmail.com>> wrote:
>>>
>>> Please let me know if you have more suggestions or corrections on
>>> this proposal.
>>> I'm tempted to submit it for review. :-)
>>>
>>> - Luis
>>>
>>> On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa
>>> mailto:lshso...@gmail.com>> wrote:
>>>
>>> It sounds good, thanks for you suggestions @Vladimir, @Patrick
>>> and @Brent.
>>>
>>> I've just updated the proposal:
>>>
>>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
>>>
>>> - Luis
>>>
>>> On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution
>>> mailto:swift-evolution@swift.org>>
>>> wrote:
>>>
>>> Yes, I feel like 'within' is much better than 'bounded'.
>>>
>>> How about such changes in proposal:
>>>
>>> a[bounded: -1 ..< 5]  -->  a[within: -1 ..< 5]  (or a[inside:
>>> -1 ..< 5] )
>>>
>>> a[optional: 0 ..< 5]  -->  a[checking: 0 ..< 5]
>>> a[optional: 5]-->  a[checking: 5]
>>>
>>> ?
>>>
>>> On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:
>>>
>>> I like the idea of the of the bounded subscript, however
>>> the optional one I
>>> feel could be used for clumsy code.
>>>
>>> .first and .last have value, but once you start stepping
>>> several arbitrary
>>> indices in, then that code is likely fragile?
>>>
>>>
>>> I can think of ‘within’, ‘inside’ and ‘intersecting’ as
>>> alternative names
>>> for ‘bounded’ that attempt to explain what is going on:
>>>
>>> let a = [1, 2, 3]
>>>
>>> a[within: 0 ..< 5] // [1, 2, 3]
>>> a[inside: 0 ..< 5] // [1, 2, 3]
>>> a[intersecting: 0 ..< 5] // [1, 2, 3]
>>>
>>>
>>> On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa
>>> via swift-evolution
>>> >> 
>>> >> >> wrote:
>>>
>>> As we have discussed throughout this thread, the
>>> initial proposal was
>>> modified to include alternative subscript methods
>>> instead of modifying
>>> the default operator/subscript behaviour.
>>> The first draft is
>>> here:
>>>
>>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
>>>
>>>   

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

On 15 May 2016, at 15:05, Brent Royal-Gordon via swift-evolution 
 wrote:

>> There we are. I read the declaration of the function from beginning to end
>> and gradually formed a rough understanding of it without needing to change
>> my expectations halfway through. I still have doubts about 'insertCount',
>> but I was at least able to formulate an hypothesis about its use.
>> 
>> YMMV, but as far as I'm concerned, the original declaration was much easier
>> to understand.
> 
> I actually agree with you for this case, but not *all* type information *has* 
> to be moved to the end. Try this on for size, which is actually still the 
> most natural way to write this declaration in SE-0081:
> 
> internal func _arrayOutOfPlaceReplace
> 
> (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int)
>  where
>  C.Iterator.Element == B.Element,
>  B.Index == Int
> {
> 
> Now only the relatively unimportant details—that the buffer and collection 
> must have elements of the same type, and that the buffer must have integer 
> indices—are at the end, whereas the basic conformances required to make any 
> sense at all of the declaration are still inline.
> 
> This proposal *permits* you to hollow out the generic parameter list to the 
> point of vacuousness, but that doesn't mean it's the right thing to do. It 
> might make sense to ban a direct `X: Foo` requirement unless there was 
> already an `X: Bar` in the generic parameter list. Or we might simply need to 
> paraphrase the Perl manual page: "There are several ways to write a generic 
> requirement, so consider picking the most readable one."

I think you hit the nail on the head. Being able to let the developer decide 
how to place relevant type information with the freedom of being able to keep 
some/all/none type information local and some/none/all extra information moved 
to the end of the declaration. Don't we allow the same kind of freedom with 
protocols and extensions in a way?


> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> There we are. I read the declaration of the function from beginning to end
> and gradually formed a rough understanding of it without needing to change
> my expectations halfway through. I still have doubts about 'insertCount',
> but I was at least able to formulate an hypothesis about its use.
> 
> YMMV, but as far as I'm concerned, the original declaration was much easier
> to understand.

I actually agree with you for this case, but not *all* type information *has* 
to be moved to the end. Try this on for size, which is actually still the most 
natural way to write this declaration in SE-0081:

internal func _arrayOutOfPlaceReplace
 
 (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int)
  where
  C.Iterator.Element == B.Element,
  B.Index == Int
{

Now only the relatively unimportant details—that the buffer and collection must 
have elements of the same type, and that the buffer must have integer 
indices—are at the end, whereas the basic conformances required to make any 
sense at all of the declaration are still inline.

This proposal *permits* you to hollow out the generic parameter list to the 
point of vacuousness, but that doesn't mean it's the right thing to do. It 
might make sense to ban a direct `X: Foo` requirement unless there was already 
an `X: Bar` in the generic parameter list. Or we might simply need to 
paraphrase the Perl manual page: "There are several ways to write a generic 
requirement, so consider picking the most readable one."

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Dmitri Gribenko via swift-evolution]

On Sat, May 14, 2016 at 7:45 AM, Daniel Steinberg via swift-evolution
 wrote:
> I appreciate your rework on this - I still don’t understand one thing and
> disagree with a second:
>
> (1) I don’t understand what the word “Custom” adds to
> CustomStringRepresentable and CustomDebugStringRepresentable and would drop
> that prefix (even if it remains Convertible).

In Swift, every value has a string and a debugging string
representation, synthesized by the runtime.  These protocols allow
customizing the default behavior.  We don't want users to write any
APIs against these protocols, because it is the wrong thing to do.

In Swift 1, when the protocols were named Printable and
DebugPrintable, many users wrote APIs like this:

func printAll(_ values: [Printable]) {
  for x in values { print(x) }
}

'Printable' is a wrong constraint.  Everything is printable, and
user-defined types that are happy with the default string
representation don't customize it; structural types (function types,
tuples) can not adopt a protocol at all.  Users can't pass instances
of such types to this overconstrained API.  The right API to design
is:

func printAll(_ values: [Any]) {
  for x in values { print(x) }
}

Motivation behind renaming Printable to CustomStringRepresentable was
to discourage writing APIs against these protocols.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Using Union instead of Generic Enum to implement Optional

[Cao Jiannan via swift-evolution]

This is the example implemented with generic and enum.

enum UnionOf3 {
case type0(T)
case type1(U)
case type2(V)
}

func input(value: UnionOf3) {
switch value {
case let .type0(a):
print(a)
case let .type1(b):
print(b)
case let .type2(c):
print(c)
}
}

let a = A()
input(UnionOf3.type0(a))

For each different number N of types to get union, you should announce UnionOfN 
for each.
it is more complicated then the union solution. 

func input(value: (A | B | C)) {
switch value {
case a as A:
print(a)
case b as B:
print(b)
case let .type2(c):
print(c)
}
}

let a= A()
input(a)


And the most bad thing is,
compiler doesn’t know the type relation between generic union with original 
type,
 for example, the type relation between A and A | B and A | B | C.

compare:

enum UnionOf3 {
case type0(T)
case type1(U)
case type2(V)
}

let a = A()
let union: UnionOf3 = UnionOf3.type0(a) // You should wrap by yourself.

a == union // probably the compiler will refuse to compare.

sub-typing: 

var fn0: A->Void = {print($0)}
var fn1: UnionOf2->Void = {print($0)}

fn0 = fn1 // This should be allowed. But will be rejected since using enum.

var fn2: UnionOf3->Void = {print($0)}

fn0 = fn2 // This should be allowed. But will be rejected since using enum.
fn1 = fn2 // This should be allowed. But will be rejected since using enum.


---

If using union, this problem can be solved easily.

let a = A()
let union: (A|B|C) = a // Automatically wrap.

a == union // Yes

sub-typing: 

var fn0: A->Void = {print(v0)}
var fn1: (A|B)->Void = {print(v0)}

fn0 = fn1 // OK

var fn2: (A|B|C)->Void = {print($0)}

fn0 = fn2 // OK
fn1 = fn2 // OK


> 下面是被转发的邮件：
> 
> 发件人: Cao Jiannan via swift-evolution 
> 主题: [swift-evolution] Fwd: Union instead of Optional
> 日期: 2016年5月15日 GMT+8 18:34:44
> 收件人: Adrian Zubarev via swift-evolution 
> 回复－收件人: Cao Jiannan 
> 
> for example, there is a method input union of 3 types: A, B, C,
> 
> This is the three class.
> 
> class A {}
> 
> class B {}
> 
> class C {}
> 
> This is how it implemented under Swift 2:
> 
> enum UnionABC {
> case classA(A)
> case classB(B)
> case classC(C)
> }
> 
> func input(value: UnionABC) {
> 
> }
> 
> let a = A()
> let b = B()
> let c = C()
> input(UnionABC.classA(a))
> 
> 
> It needs announce all the cases and name each cases and cannot use class 
> names as their case names.
> 
> what about using union? It is more easy and rational.
> 
> 
> func input(value: (A | B | C)) {
> 
> }
> 
> let a= A()
> input(a)
> 
> Or you can implement it with protocol and extension, but compiler will not 
> know how many cases it should have.
> 
> 
> protocol UnionABC {
> 
> }
> 
> extension A: UnionABC {}
> extension B: UnionABC {}
> extension C: UnionABC {}
> 
> 
> func input(value: UnionABC) {
> if value is A {
> 
> } else if value is B {
> 
> } else if value is C {
> 
> } else {
> // There are other cases? Compiler doesn't know
> }
> }
> 
> let a = A()
> input(a)
> 
> 
> 
>> 下面是被转发的邮件：
>> 
>> 发件人: frog...@163.com 
>> 主题: 回复： [swift-evolution] Union instead of Optional
>> 日期: 2016年5月15日 GMT+8 18:00:55
>> 收件人: Austin Zheng mailto:austinzh...@gmail.com>>
>> 
>> 
>> Enum and Union are two things.
>> 
>> If you use Enum to implement Union, you should announce it with case name.
>> 
>> Another issue using enum instead of union is that,  union can combine types 
>> as many as possible, you just write ( A | B | C ... | Z), but for enum, you 
>> should carefully announce it for each case. 
>> 
>> 在 2016年5月15日，15:22，Austin Zheng > > 写道：
>> 
>>> In addition, not everything in Swift can be modeled in terms of inheritance 
>>> relationships.
>>> 
>>> I'm a little curious as to why union types keep on coming up, when enums 
>>> can do everything they can and much more (methods, constraints on generic 
>>> types, conformance to protocols).
>>> 
>>> Austin
> 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

Re: [swift-evolution] Union instead of Optional

[Tino Heth via swift-evolution]

I don't know if there has been any internal discussion about using union-types 
instead of enums, but afaics, there are no obvious downsides for that approach.

> I'm a little curious as to why union types keep on coming up, when enums can 
> do everything they can and much more (methods, constraints on generic types, 
> conformance to protocols).
Are there any strong reasons why those features would not be possible with 
union types?

There has been a discussion started because it is a little bit cumbersome to 
create enum-properties (and methods).
With unions, there would be no need for all those switch-statements, and would 
be possible to configure cases in a central location.
There has also been a proposal for "anonymous enums", which could be modeled 
with unions in a very elegant way.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nicola Salmoria via swift-evolution]

David Hart via swift-evolution  writes:

> 
> 
> Hi Karl,
> 
> As author of this proposal, the one about constraints on associated types,
and the one on type-aliases in protocols (all from the Generics Manifesto -
original authorship to Douglas Gregor) I’d like to provide additional
reasoning behind my wish to push this proposal through, as a whole.
> 
> First of all, there is a personal preference. I’ve used C# for many many
years, which has its where clause at the end of the declaration (like this
proposal), and I’ve used Swift since its unveiling. The experience with
using both styles for several years makes me favour this proposal’s syntax
because I find it much easier to read and format for readability.
> 
> Constraints on associated type will provide more expressivity but I doubt
it will greatly reduce protocol constraint clauses in a majority of cases.
And yes, type-aliases in protocols will shorten clauses, but I still think
they will more readable with the where clause at the end.
> 
> For example, here is a method I took (as-is) from the Standard Library
which has a few constraints, and which I further simplified if we imagine
that Sequence has an Element typealias for Iterator.Element:
> 
> 
> internal func _arrayOutOfPlaceReplace<
>  B : _ArrayBufferProtocol, C : Collection
>  where  C.Element == B.Element,
>  B.Index == Int
> >(  _ source: inout B, _ bounds: Range, _ newValues:
> C, _ insertCount: Int) {
> 
> See how the Standard Library authors formatted it for readability and how
as a consequence arguments which use the generic types are further apart
from the declaration of those generic types. But with this proposal, the
declaration might be formatted to:
> 
> internal func _arrayOutOfPlaceReplace(_ source: inout B,
> _ bounds: Range, _ newValues: C, _ insertCount: Int)
>  where
>  B : _ArrayBufferProtocol,
>  C : Collection,
>  C.Iterator.Element == B.Element,
>  B.Index == Int
> {
> 
> Do you need believe this is now more readable?
> 
> David.

Thanks for the real world example!

I think that the second arguably *looks* better. But is it more *readable*?
Not for me.

Let me try to do a brain dump while I mentally parse the declaration.

> internal func _arrayOutOfPlaceReplace(

Mmm, here we have a function that has something to do with arrays, generic
on two types. Maybe it will take an Array and output an Array?

> _ source: inout B,

Ah, the first argument is a B that will be changed. Maybe the function deals
with Array and will replace occurrences of 'source' with something else?

> _ bounds: Range,

Ok, this surely must be the range of the Array to operate on.

> _ newValues: C,

Oh, this parameter is called 'newValues', so C can't be a single value. It
must be a Collection, surely.

> _ insertCount: Int)

... I can't figure out what this could be.

>  where
>  B : _ArrayBufferProtocol,

Oh, B was some kind of buffer. OK so the function probably takes this
buffer, and replaces 'range' with 'newValues'

>  C : Collection,
>  C.Iterator.Element == B.Element,

Good, this confirms what I thought.

>  B.Index == Int

Looks like an implementation detail, I guess that's why 'range' is a
Range and 'insertCount' is an Int. Presumably the function needs to do
some operations that the generic Index doesn't guarantee.

So that's the end of it. I have a vague idea of what the function might do,
and had to revise my expectations a few times while reading its declaration.


Let's try again with the original declaration.

> internal func _arrayOutOfPlaceReplace<
>  B : _ArrayBufferProtocol, C : Collection

OK, here we have a function that deals with Arrays, generic on some buffer
thing and on a Collection. B is presumably what it needs to operate on, and
C will be the thing to replace with.

>  where  C.Element == B.Element,

Indeed thic confirms that B and C must be compatible.

>  B.Index == Int

Looks like an implementation detail, presumably we need to indicate the
position in the array where to do the replace.

> >(  _ source: inout B,

OK so this is a mutating function, and B is a buffer that will be modified.

> _ bounds: Range,

This is probably the range of the buffer that needs to be replaced, indeed
we had B.Index == Int.

> _ newValues: C,

And this collection contains what we need to insert in the buffer.

> _ insertCount: Int) {

Not sure what this might be, maybe the function will copy only the first
'insertCount' elements of C.

There we are. I read the declaration of the function from beginning to end
and gradually formed a rough understanding of it without needing to change
my expectations halfway through. I still have doubts about 'insertCount',
but I was at least able to formulate an hypothesis about its use.

YMMV, but as far as I'm concerned, the original declaration was much easier
to understand.

Now if we had generic typealiases, we could do something like

typealias CollectionOf = protocol where Collection.Element == T

and if my intuition about B.Index is right, the declar

[swift-evolution] Fwd: Union instead of Optional

[Cao Jiannan via swift-evolution]

for example, there is a method input union of 3 types: A, B, C,

This is the three class.

class A {}

class B {}

class C {}

This is how it implemented under Swift 2:

enum UnionABC {
case classA(A)
case classB(B)
case classC(C)
}

func input(value: UnionABC) {

}

let a = A()
let b = B()
let c = C()
input(UnionABC.classA(a))


It needs announce all the cases and name each cases and cannot use class names 
as their case names.

what about using union? It is more easy and rational.


func input(value: (A | B | C)) {

}

let a= A()
input(a)

Or you can implement it with protocol and extension, but compiler will not know 
how many cases it should have.


protocol UnionABC {

}

extension A: UnionABC {}
extension B: UnionABC {}
extension C: UnionABC {}


func input(value: UnionABC) {
if value is A {

} else if value is B {

} else if value is C {

} else {
// There are other cases? Compiler doesn't know
}
}

let a = A()
input(a)



> 下面是被转发的邮件：
> 
> 发件人: frog...@163.com
> 主题: 回复： [swift-evolution] Union instead of Optional
> 日期: 2016年5月15日 GMT+8 18:00:55
> 收件人: Austin Zheng 
> 
> 
> Enum and Union are two things.
> 
> If you use Enum to implement Union, you should announce it with case name.
> 
> Another issue using enum instead of union is that,  union can combine types 
> as many as possible, you just write ( A | B | C ... | Z), but for enum, you 
> should carefully announce it for each case. 
> 
> 在 2016年5月15日，15:22，Austin Zheng  > 写道：
> 
>> In addition, not everything in Swift can be modeled in terms of inheritance 
>> relationships.
>> 
>> I'm a little curious as to why union types keep on coming up, when enums can 
>> do everything they can and much more (methods, constraints on generic types, 
>> conformance to protocols).
>> 
>> Austin
 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] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Tino Heth via swift-evolution]

> Tino, would you like to form an 'official' proposal for this(newlines as 
> separators) feature? As I can see, there is a much support in community for 
> this idea, but no one said yet he/she will create a proposal for this.(or I 
> just missed this)
I feel honored, but I guess there are others (native speaker, closer relation 
to the core team...) who are better suited than me...
On the other hand, I lack fear of seeing a proposal rejected ;-), so as long as 
deeper thinking doesn't reveal any downsides, I don't mind spending some hours 
and putting my name on the pull request.
Afaics, there are no plans to change SE-0084 to at least add "making commas 
optional if followed by a newline" as an alternative, so the first step would 
be a separate thread ("Newlines as item separators in lists"?) — but as all 
examples in the proposal use commas followed by newlines, I think all of its 
goals could be archived 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Union instead of Optional

[Cao, Jiannan via swift-evolution]

Optional should be implement by union concept s instead of using generic.

Enum cannot be easily used to represent many types until you name all of them. 

Both generic and enum solution cannot build a strong relation between optional 
type and its original type, for example, an Integer type has no reparation with 
Optional, until the compiler make a special case for Optional to 
automatically unwrap or wrap for this.

> 在 2016年5月15日，15:19，David Hart  写道：
> 
> Enums with associated types in Swift are the equivalent of unions, even if 
> they don’t have the name. I don’t see what your proposal is trying to solve?
> 
>> On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution 
>>  wrote:
>> 
>> 
>> It’s kind of same idea of TypeScipt 2, at 46:21 in this video.
>> 
>> https://channel9.msdn.com/Events/Build/2016/B881
>> 
>> <屏幕快照 2016-05-15 10.20.36.png>
>> 
>> 
>>> 
>>> 2016-2-16 GMT+8 14:36:28
>>> Hi all,
>>> 
>>> I think the best way to solve the either problem is to separate it from 
>>> generic. 
>>> Optional and Either shouldn’t work the same way of generic type. 
>>> It’s just a represent of multiple type in one location.
>>> 
>>> Using an old friend, Union in C.
>>> union {
>>> case firstType
>>> case secondType
>>> }
>>> 
>>> This is the final solution for the sub typing problem of optional.
>>> 
>>> A  == union(A,A)
>>> union(A,B) == union(B,A)
>>> B == union(B,B)
>>> 
>>> B is subtype of union(A,B)
>>> A is subtype of union(A,B)
>>> union(A,B,C) is subtype of union(A,B,C,D,…)
>>> 
>>> suppose 
>>> a is subclass of A
>>> b is subclass of B, then
>>> union(a,B) is subtype of union(A,B)
>>> union(A,b) is subtype of union(A,B)
>>> union(a,b) is subtype of union(a,B)
>>> union(a,b) is subtype of union(A,b)
>>> 
>>> union can have as many case as possible. e.g., union(A,B,C,D,…)
>>> 
>>> So the Optional should be union(UITableView, None)
>>> and Optional should be union(MyTableView, None), which is 
>>> subclass of union(UITableView, None)
>>> 
>>> This is a final rational solution. I think.
>>> 
>>> -Jiannan
>> 
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote:

One point which should be discussed is the following behaviour:

let array = [0]
// ranges are completely out of bounds and produce an error
array[clamping: 1...2] // error
array[clamping: -2...-1] // error

Should a range which has no intersection with the indices of the collection
produce an error or just clamp to 0..<0 respectively endIndex..

I expect it will returns [] i.e. empty array, as no elements with 
1...2(-2..-1) indexes in the array. I understand `clamping` similar as 
'bounded','in these bounds'. And as soon as [0,1,2,3,4][clamping:2...10] 
will silently move the right position to allowed index(4), and 
[0,1,2,3,4][clamping:-2...0]  will move left position to 0, I expect that 
in [0][clamping: 1...2] will try to move both limits to allowed, and as no 
intersection - silently return empty array.




Best regards
Maximilian

Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution
mailto:swift-evolution@swift.org>>:


It seems that there is a consensus that this proposal might be a good
addition to the standard library. All comments on this thread in the past
few weeks were related to naming, not around the behaviour or validity of
the proposed methods. So I will submit this proposal for review very soon
assuming that nobody else has strong arguments against it. :-)

Proposal: 
https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md

If you have any corrections or suggestions to the proposal text itself,
please comment on this gist:
https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
(or pull request to my repo)

Regards,

- Luis

On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa
mailto:lshso...@gmail.com>> wrote:

Please let me know if you have more suggestions or corrections on
this proposal.
I'm tempted to submit it for review. :-)

- Luis

On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa
mailto:lshso...@gmail.com>> wrote:

It sounds good, thanks for you suggestions @Vladimir, @Patrick
and @Brent.

I've just updated the proposal:

https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design

- Luis

On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution
mailto:swift-evolution@swift.org>> wrote:

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

How about such changes in proposal:

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

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

?

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

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

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


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

let a = [1, 2, 3]

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


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

As we have discussed throughout this thread, the
initial proposal was
modified to include alternative subscript methods
instead of modifying
the default operator/subscript behaviour.
The first draft is
here:

https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md

I've also put this as a gist so that you can leave
comments with respect
to the proposal document itself. Any suggestion or
help is very welcome.

https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8

Regards,

- Luis

On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa
mailto:lshso...@gmail.com>
>> wrote:

 

Re: [swift-evolution] [Pitch] merge types and protocols back together with type

[Adrian Zubarev via swift-evolution]

I think an important point is that `all<>` should NOT be restricted to having 
only one reference or value type!
This is a little problematic and I’m not a compiler expert so from my 
perspective I could allow that but in a different way you see it (I’ll explain 
below).

Ceylon does not have any restrictions like that. You can form the type 
intersection of String and Integer for example, which are both classes in 
Ceylon and because Ceylon like Swift only knows single inheritance between 
classes, the result is simply `Nothing` (the bottom type which has no 
elements). So there is no need to forbid this explicitly, because the types 
work out just fine.
If I remember correctly someone said that `Ceylon` does use `all` and `any` for 
its Optional?! We can’t to do this in Swift as far as I know our playground.

We don’t have `Nothing` in Swift. The counterpart would be `Optional` but such 
a type is made explicit by `?` symbol like `Type? == Optional` and the 
only equivalent to `Nothing` would be `nil`.

That been said, if `All<>` would always intersect (what I haven’t proposed here 
at all) we can’t replace `protocol<>` with `All<>` because if we look at two 
distinct protocols `A` and `B` and try to merge them into a type `All` 
would resolve in `implicit nil` where the old fashion way is not `protocol`. By the way, really an `implicit nil`? This is not a great idea if you ask 
me. 

You may have a look at this document: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

`All == implicit nil` (your way) while it probably `All? == nil` would serve your wished behavior, but again I wasn’t proposing on 
solving this issue here. I’d like to solve this problem 
https://openradar.appspot.com/20990743 and open the door for `AnyStruct`, 
`AnyEnum`, `AnyValue` (maybe `AnyTuple` someday). This is what your hint for 
`Any<>` combined with my `All<>` might create.

If we allow multiple reference and value types for `All<>` this will only work 
with subtypeable types, because as I already described above `All` can’t be merged.

A scenario that will work might look like this:

class A {}     class B: A {}     class C: B {}

`All` from the given types and my understanding the compile could and 
should infer `C` from here (not `B` compared to your example below).

To sum up a little we would have these facts:

- for subtypeable types the compile will search the highest type from the 
inheritance path and ignore all other lower base types (for `All` the 
compile would infer `B == All == All`)

- the oder of types should not matter because of the previous fact

That been said do we still need the whole inheritance branch inside of `All<>`? 
I don’t think so.

Furthermore if we definitely should ignore order of `Types` inside the angle 
brackets like `All == All`, because it makes sense from the context 
of creating a `Type` that is constrained to `A` AND `B` where AND is 
commutative. I didn’t thought of at first glance, but thanks to your examples 
it’s clear to me know.

———

If one would want to store or pass `A` from `class A: ClassB, ProtocolC` in 
some generic context and we don’t allow a second reference for `All<>` the 
following sample won’t work (generalized `class` is assumed):

`func (value: All)` but you can workaround here 
`func (value: All)` which can already be done `func 
(value: T)`

The only problem that rises up here is that we can’t store that value inside a 
non-generic `Type` with both distinct `ClassB` and `ProtocolC` constraints 
merged together. As you might guess `ProtocolC` is applied onto `A` but not on 
`B` where `All` will create a whole new type for us 
(https://openradar.appspot.com/20990743).

Furthermore you can form type intersections between reference types which 
inherit from each other. The resulting intersection type is valid and is just 
equal to the more specific type. And of course you can form type intersections 
of a reference or value type with itself (i.e. all).
Why should that be useful you may ask?

This generality is important when using intersection types with generics: let’s 
consider the type of a function forming the intersection of two sets with 
different element types:

func union(a: Set, b: Set) -> Set> { … }


Requiring all to have at most one reference or value type (which must be 
at first position) would impose some unnecessary restrictions:

Given the following:

protocol Named {}
class Person : Named {}
class Employee : Person {}

let people: Set
let otherPeople: Set
let employees: Set
let namedOnes: Set

// unnecessary restriction:
let x1 = union(namedOnes, people)  // not allowed, because result type contains 
all 
// the restriction would require us to write:
let x2 = union(people, namedOnes)  // ok, result type would be Set> which would be simplified by the compiler to Set (Ceylon does 
this!)
// unnecessary restriction:
let x3 = union(people, employees)   // not allowed, because result type would 
contain all with two reference type

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Jean-Daniel Dupas via swift-evolution]

I really don’t like that proposal too.

While I can understand why it may be useful for list, I find it very confusing 
to allow it in function declaration. 
The motivation do not apply here. You can’t simply remove a parameter or 
reorder that without breaking all code that use that function (even function 
with default parameter as the parameter may be explicitly defined at invocation 
site).

Even in other places (list, enum, …), I think the kind of refactoring describe 
in the motivation is not something that is common enough to introduce that kind 
of syntax change.

And the fact that no alternative was investigated (like allowing new line as 
separator) make me think this proposal is not complete and shouldn’t be 
accepted as is anyway.

Jean-Daniel

> Le 14 mai 2016 à 21:25, Kenny Leung via swift-evolution 
>  a écrit :
> 
> I am against this proposal.
> 
> - I think it makes the code look ugly and incomplete when there is a trailing 
> comma
> - I much prefer the counter-proposal which would allow newline to be the 
> separator for items in a list.
>- in general, it’s much better when you can remove something from your 
> code rather than add something to it
>- this proposal serves the same purpose as allowing the trailing comma
> 
> -Kenny
> 
> 
>> On May 10, 2016, at 11:53 AM, Chris Lattner  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0084: Allow trailing commas in parameter lists and tuples" 
>> begins now and runs through May 16. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[L. Mihalkovic via swift-evolution]

> On May 15, 2016, at 9:17 AM, David Hart  wrote:
> 
> Hi Karl,
> 
> As author of this proposal, the one about constraints on associated types, 
> and the one on type-aliases in protocols (all from the Generics Manifesto - 
> original authorship to Douglas Gregor) I’d like to provide additional 
> reasoning behind my wish to push this proposal through, as a whole.
> 
> First of all, there is a personal preference. I’ve used C# for many many 
> years, which has its where clause at the end of the declaration (like this 
> proposal), and I’ve used Swift since its unveiling. The experience with using 
> both styles for several years makes me favour this proposal’s syntax because 
> I find it much easier to read and format for readability.
> 
> Constraints on associated type will provide more expressivity but I doubt it 
> will greatly reduce protocol constraint clauses in a majority of cases. And 
> yes, type-aliases in protocols will shorten clauses, but I still think they 
> will more readable with the where clause at the end.
> 
> For example, here is a method I took (as-is) from the Standard Library which 
> has a few constraints, and which I further simplified if we imagine that 
> Sequence has an Element typealias for Iterator.Element:
> 
> 
> internal func _arrayOutOfPlaceReplace<
>   B : _ArrayBufferProtocol, C : Collection
>   where
>   C.Element == B.Element,
>   B.Index == Int
> >(
>   _ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int
> ) {
> 
> See how the Standard Library authors formatted it for readability and how as 
> a consequence arguments which use the generic types are further apart from 
> the declaration of those generic types. But with this proposal, the 
> declaration might be formatted to:
> 
> internal func _arrayOutOfPlaceReplace(_ source: inout B, _ bounds: 
> Range, _ newValues: C, _ insertCount: Int) where
>   B : _ArrayBufferProtocol,
>   C : Collection,
>   C.Iterator.Element == B.Element,
>   B.Index == Int
> {

Reading this example reinforces my initial sense that while WHERE works well 
when the information is inlined, I would have preferred WITH in the case where 
the information is at the end. go figure...


> 
> Do you need believe this is now more readable?
> 
> David.
> 
>> On 15 May 2016, at 02:26, Karl Wagner via swift-evolution 
>>  wrote:
>> 
>> There is a lot not to like about the idea; even if it was optional. 
>> Personally, I feel the problem is solved in a much, much more elegant manner 
>> by other proposals.
>> 
>> Firstly, the stuff after the ‘where’ clause is getting shorter once 
>> typealiases come to protocols. C.Iterator.Element become C.Element. In this 
>> one example, that’s 18 characters down to 9 - a 50% reduction in length. We 
>> tend to use quite expressive names for associated types, so I expect we’ll 
>> see similar gains elsewhere from this very simple proposal.
>> 
>> Not only that, but there’s a very good proposal to add ‘where’ clauses to 
>> associated types in the protocols themselves, which will likely further 
>> reduce the verbosity of the constraints you need to specify at each 
>> declaration site. 
>> https://github.com/hartbit/swift-evolution/blob/9acd75abfbe626bbb3f9458cc3f6edb1d1f88c95/proposals/-associated-types-constraints.md
>> 
>> And then we have generic typealiases and generalised existentials, which 
>> would allow us to wrap those ‘where’ clauses in to something much more 
>> intelligible to a human being at first glance. ‘StringCollection’ or 
>> ‘CollectionOfStrings’ is much clearer than > C.Element==String>, no matter how you chop it up.
>> 
>> If I look at the other proposals, and where we are headed with much more 
>> expressive typealiases and associated types, I just feel that that’s the 
>> future: that’s the “swift’ way. It’s like type inference - all of the strict 
>> constraints are still there under-the-hood, but you’re able to work at a 
>> much clearer and more obvious abstraction level. This proposal pulls us 
>> further away from things like ‘obviousness’, and like I said, simply feels 
>> like an inelegant solution.
>> 
>> At the very least, I think we should shelve the discussion until the larger 
>> expansion of typealiases, etc is complete. We should re-evaluate at that 
>> time, with a bigger set of more general-purpose tools to produce readable 
>> code.
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Union instead of Optional

[Austin Zheng via swift-evolution]

In addition, not everything in Swift can be modeled in terms of inheritance 
relationships.

I'm a little curious as to why union types keep on coming up, when enums can do 
everything they can and much more (methods, constraints on generic types, 
conformance to protocols).

Austin

> On May 15, 2016, at 12:19 AM, David Hart via swift-evolution 
>  wrote:
> 
> Enums with associated types in Swift are the equivalent of unions, even if 
> they don’t have the name. I don’t see what your proposal is trying to solve?
> 
>> On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> It’s kind of same idea of TypeScipt 2, at 46:21 in this video.
>> 
>> https://channel9.msdn.com/Events/Build/2016/B881 
>> 
>> 
>> <屏幕快照 2016-05-15 10.20.36.png>
>> 
>> 
>>> 
>>> 2016-2-16 GMT+8 14:36:28
>>> Hi all,
>>> 
>>> I think the best way to solve the either problem is to separate it from 
>>> generic. 
>>> Optional and Either shouldn’t work the same way of generic type. 
>>> It’s just a represent of multiple type in one location.
>>> 
>>> Using an old friend, Union in C.
>>> union {
>>> case firstType
>>> case secondType
>>> }
>>> 
>>> This is the final solution for the sub typing problem of optional.
>>> 
>>> A  == union(A,A)
>>> union(A,B) == union(B,A)
>>> B == union(B,B)
>>> 
>>> B is subtype of union(A,B)
>>> A is subtype of union(A,B)
>>> union(A,B,C) is subtype of union(A,B,C,D,…)
>>> 
>>> suppose 
>>> a is subclass of A
>>> b is subclass of B, then
>>> union(a,B) is subtype of union(A,B)
>>> union(A,b) is subtype of union(A,B)
>>> union(a,b) is subtype of union(a,B)
>>> union(a,b) is subtype of union(A,b)
>>> 
>>> union can have as many case as possible. e.g., union(A,B,C,D,…)
>>> 
>>> So the Optional should be union(UITableView, None)
>>> and Optional should be union(MyTableView, None), which is 
>>> subclass of union(UITableView, None)
>>> 
>>> This is a final rational solution. I think.
>>> 
>>> -Jiannan
>>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Union instead of Optional

[David Hart via swift-evolution]

Enums with associated types in Swift are the equivalent of unions, even if they 
don’t have the name. I don’t see what your proposal is trying to solve?

> On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution 
>  wrote:
> 
> 
> It’s kind of same idea of TypeScipt 2, at 46:21 in this video.
> 
> https://channel9.msdn.com/Events/Build/2016/B881 
> 
> 
> <屏幕快照 2016-05-15 10.20.36.png>
> 
> 
>> 
>> 2016-2-16 GMT+8 14:36:28
>> Hi all,
>> 
>> I think the best way to solve the either problem is to separate it from 
>> generic. 
>> Optional and Either shouldn’t work the same way of generic type. 
>> It’s just a represent of multiple type in one location.
>> 
>> Using an old friend, Union in C.
>> union {
>>  case firstType
>>  case secondType
>> }
>> 
>> This is the final solution for the sub typing problem of optional.
>> 
>> A  == union(A,A)
>> union(A,B) == union(B,A)
>> B == union(B,B)
>> 
>> B is subtype of union(A,B)
>> A is subtype of union(A,B)
>> union(A,B,C) is subtype of union(A,B,C,D,…)
>> 
>> suppose 
>> a is subclass of A
>> b is subclass of B, then
>>  union(a,B) is subtype of union(A,B)
>>  union(A,b) is subtype of union(A,B)
>>  union(a,b) is subtype of union(a,B)
>>  union(a,b) is subtype of union(A,b)
>> 
>> union can have as many case as possible. e.g., union(A,B,C,D,…)
>> 
>> So the Optional should be union(UITableView, None)
>> and Optional should be union(MyTableView, None), which is 
>> subclass of union(UITableView, None)
>> 
>> This is a final rational solution. I think.
>> 
>> -Jiannan
>> 
> 
> 
> 
> 
> ___
> 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] "AnyValue", "protocol MyProtocol : value" as counterpart to "AnyObject", ": class"

[Adrian Zubarev via swift-evolution]

Might have a look at this thread, where value semantics is been discussed 
already: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html
 (Should we rename "class" when referring to   protocol conformance?)

I’m also proposing for a `Type` merging mechanism with the potential to replace 
`protocol<>` called `type<>` aka. `all<>` aka. `All<>` (and in some point the 
core team names a portion of it `Any<>` in their docs: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md).

My proposal thread is here: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016523.html
 ([Pitch] merge types and protocols back together with type)

If you want to read my detailed design, take a look at this WIP draft: 
https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-merging-types-with-protocols.md
 
I will rewrite a few things when I find some time to match a few things from 
the GenericsManifesto.

Anyways may I sum a few of my thoughts up for you:

- from the GenericsManifesto we “might“ see something like “Generalized `class` 
constraints“ in Swifts future: `typealias AnyObject = protocol`

- if my proposal will be accepted and `class` is generalized already we’ll have 
something like this: `typealias AnyObject = All`
        * `All<>` will create a type from all constraints inside the angle 
brackets, this will create a new `Type` like `All` where 
`SomeProtocol` sits on the .dynamicType rather than on `UIView`
        * this will solve this problem https://openradar.appspot.com/20990743
        * future flattened version of `All<>` might have operators and could be 
expressed like this: `func foo(value: UIView & SomeProtocol)`

- there are two future directions in my proposal: 
       (1) `Any<>` which takes only one type from the angle brackets: 
`Any` or `String | Int`
       (2) if we already have a generalized `class` keyword, so why we don’t 
get `struct` and `enum` as well?

With this we can create a typealias for `AnyValue` like this (at least for 
generalized extendable types): 
       `typealias AnyStruct = All`
       `typealias AnyEnum = All`
       `typealias AnyValue = Any, All>`
       `typealias AnyValue = AnyStruct | AnyEnum`

The future might also see:  `typealias AnyValue = Any, All, 
All>`

But again I have to rewrite a lot of things in my proposal towards this 
direction. ;)

-- 
Adrian Zubarev
Sent with Airmail

Am 15. Mai 2016 bei 05:20:29, Karl via swift-evolution 
(swift-evolution@swift.org) schrieb:

I was building a collection object recently, which stores an array of tuples: 
(Range, T) - some generic type, and a range.  
Part of the workings of the collection involves splitting these tuples, which 
means we need to split the Range (easy enough) and duplicate T.

In practice, I was using value types for T (it was another Array), so I could 
duplicate by assignment; but what if somebody stuck an NSArray or other 
reference-type in instead?

My first thought was - I could allow it, create some “Copyable” protocol and 
require conformance. But there are other guarantees I get from value types as 
well. Let’s say I had a sorted Array of T; if T could be a reference-type, 
anybody who gets a T from the collection could mutate it and invalidate the 
sort order at any time! That could lead to unexpected behaviour, such as 
infinite loops in binary-search algorithms, and it might not be obvious to a 
user of the collection how that happened (or that it’s even their fault - how 
are they supposed to know this is kept in a sorted Array, especially if it’s 
wrapped by another type, and that this particular search algorithm could 
infinitely loop if the Array is not sorted?). I could return a copy from the 
getter, but at this point I’m basically re-inventing value-type semantics for 
classes while creating burdensome requirements for actual value-types.

Actually, this is a problem with the language in general. While we have a way 
to specify that a generic type or protocol must obey reference-type semantics 
(via “”, “protocol MyProtocol : class”), we don’t have a 
value-type semantic counterpart.

So I’d like to see us provide an “AnyValue” and “value” equivalent. We should 
be able to require that generic types or protocols are satisfied by values so 
we know how to treat them.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

Hi Karl,

As author of this proposal, the one about constraints on associated types, and 
the one on type-aliases in protocols (all from the Generics Manifesto - 
original authorship to Douglas Gregor) I’d like to provide additional reasoning 
behind my wish to push this proposal through, as a whole.

First of all, there is a personal preference. I’ve used C# for many many years, 
which has its where clause at the end of the declaration (like this proposal), 
and I’ve used Swift since its unveiling. The experience with using both styles 
for several years makes me favour this proposal’s syntax because I find it much 
easier to read and format for readability.

Constraints on associated type will provide more expressivity but I doubt it 
will greatly reduce protocol constraint clauses in a majority of cases. And 
yes, type-aliases in protocols will shorten clauses, but I still think they 
will more readable with the where clause at the end.

For example, here is a method I took (as-is) from the Standard Library which 
has a few constraints, and which I further simplified if we imagine that 
Sequence has an Element typealias for Iterator.Element:


internal func _arrayOutOfPlaceReplace<
  B : _ArrayBufferProtocol, C : Collection
  where
  C.Element == B.Element,
  B.Index == Int
>(
  _ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int
) {

See how the Standard Library authors formatted it for readability and how as a 
consequence arguments which use the generic types are further apart from the 
declaration of those generic types. But with this proposal, the declaration 
might be formatted to:

internal func _arrayOutOfPlaceReplace(_ source: inout B, _ bounds: 
Range, _ newValues: C, _ insertCount: Int) where
  B : _ArrayBufferProtocol,
  C : Collection,
  C.Iterator.Element == B.Element,
  B.Index == Int
{

Do you need believe this is now more readable?

David.

> On 15 May 2016, at 02:26, Karl Wagner via swift-evolution 
>  wrote:
> 
> There is a lot not to like about the idea; even if it was optional. 
> Personally, I feel the problem is solved in a much, much more elegant manner 
> by other proposals.
> 
> Firstly, the stuff after the ‘where’ clause is getting shorter once 
> typealiases come to protocols. C.Iterator.Element become C.Element. In this 
> one example, that’s 18 characters down to 9 - a 50% reduction in length. We 
> tend to use quite expressive names for associated types, so I expect we’ll 
> see similar gains elsewhere from this very simple proposal.
> 
> Not only that, but there’s a very good proposal to add ‘where’ clauses to 
> associated types in the protocols themselves, which will likely further 
> reduce the verbosity of the constraints you need to specify at each 
> declaration site. 
> https://github.com/hartbit/swift-evolution/blob/9acd75abfbe626bbb3f9458cc3f6edb1d1f88c95/proposals/-associated-types-constraints.md
>  
> 
> 
> And then we have generic typealiases and generalised existentials, which 
> would allow us to wrap those ‘where’ clauses in to something much more 
> intelligible to a human being at first glance. ‘StringCollection’ or 
> ‘CollectionOfStrings’ is much clearer than  C.Element==String>, no matter how you chop it up.
> 
> If I look at the other proposals, and where we are headed with much more 
> expressive typealiases and associated types, I just feel that that’s the 
> future: that’s the “swift’ way. It’s like type inference - all of the strict 
> constraints are still there under-the-hood, but you’re able to work at a much 
> clearer and more obvious abstraction level. This proposal pulls us further 
> away from things like ‘obviousness’, and like I said, simply feels like an 
> inelegant solution.
> 
> At the very least, I think we should shelve the discussion until the larger 
> expansion of typealiases, etc is complete. We should re-evaluate at that 
> time, with a bigger set of more general-purpose tools to produce readable 
> code.

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