Re: [swift-evolution] [Draft] Expanded min/max algorithms

[Dmitri Gribenko via swift-evolution]

On Sat, Apr 16, 2016 at 11:50 PM, Taras Zakharko via swift-evolution
 wrote:
> Hi Nate,
>
>  I think this is a very useful addition! I also had a related proposal few
> days ago:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html
>
>  I feel like min/max extension and element order belong to the same family
> of enhancements. If you are interested, maybe we can combine them together
> into a single proposal?

Thanks Nate and Taras!  I'd recommend to keep minmax and .order()
proposals separate.

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

Re: [swift-evolution] [Draft] Expanded min/max algorithms

[Taras Zakharko via swift-evolution]

Hi Nate, 

 I think this is a very useful addition! I also had a related proposal few days 
ago: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html
 

 
 I feel like min/max extension and element order belong to the same family of 
enhancements. If you are interested, maybe we can combine them together into a 
single proposal? 

Best, 

 Taras


> On 17 Apr 2016, at 08:44, Nate Cook via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> Attached is a draft of a proposal to expand the min and max sequence APIs to 
> better handle collections and to support future sorted sequences/collections. 
> The proposal is in a gist here 
>  and 
> inlined below—would love to hear any comments or feedback before submitting 
> the proposal.
> 
> Nate
> 
> 
> Proposal: Expanded min/max algorithms
> This proposal would expand on the min() and max() sequence methods to add 
> methods that return the corresponding index for a collection, efficiently 
> find the minimum and maximum elements or indices at the same time, and 
> provide extension points for sorted collections to provide all these results 
> more efficiently.
> 
> Related Bugs: SR-889  and SR-890 
> 
> Motivation
> The Sequence protocol currently offers min() and max() methods that return 
> the minimum and maximum elements of a sequence or collection. Unfortunately, 
> there are applications where these methods do not provide enough flexibility 
> to be useful.
> 
> First, if the user of a collection wants not just to get the minimum value 
> but also to operate on it in some way (e.g., mutation or just accessing it 
> multiple times), she would need the index of the minimum element. The current 
> APIs don't support that, so she would need to write her own.
> 
> Second, the writer of a sorted collection is currently unable to provide 
> efficient responses to the min() and max() methods when used in a generic 
> context, even though these should be O(1) operations. Just like Set can 
> respond quickly to contains(_:) even in a generic context, so too should new 
> sorted collections be able to optimize their responses.
> 
> Finally, getting the minimum and maximum elements (or indices) of a 
> collection or sequence currently requires calling both min() and max(). With 
> two calls, every element is iterated and compared twice. When you need both 
> results, finding both the minimum and the maximum at the same time is more 
> efficient, requiring only a single pass and 25% fewer comparisons.
> 
> Proposed solution
> This proposal has three parts:
> 
> Adding minIndex() and maxIndex() methods to Collection that return the index 
> of the minimum and maximum elements, respectively.
> 
> let numbers = [30, 40, 10, 20, 60, 50]
> 
> if let i = numbers.minIndex() {
> print("\(i): \(numbers[i])")   // 2: 10
> }
> Adding minmax() and minmaxIndices() methods to Sequence and Collection, 
> respectively, to calculate the values (or indices) of the minimum and maximum 
> elements simultaneously.
> 
> if let result = numbers.minmax() {
> // result == (minimum: 10, maximum: 60)
> // ...
> }
> if let i = numbers.minmaxIndices() {
> // i == (minimum: 2, maximum: 4)
> print("\(i.minimum): \(numbers[i.minimum])")
> }
> Adding customization points for sequences and collections that can offer more 
> efficient results: 
> _customMinComparableElement()/_customMaxComparableElement() for Sequence and 
> _customIndexOfMinComparableElement()/_customIndexOfMaxComparableElement()for 
> Collection.
> 
> Detailed design
> The following methods would be added to the visible public APIs of Sequence 
> and Collection as default implementations.
> 
> extension Sequence {
> /// Returns the minimum and maximum values of `self`, using 
> /// `isOrderedBefore` to compare elements, or `nil` if the sequence
> /// has no elements.
> func minmax(@noescape isOrderedBefore isOrderedBefore: 
> (Iterator.Element, Iterator.Element) throws -> Bool
> ) rethrows -> (min: Iterator.Element, max: Iterator.Element)?
> }
> 
> extension Sequence where Iterator.Element: Comparable {
> /// Returns the minimum and maximum values of `self`, or `nil` 
> /// if the sequence has no elements.
> func minmax() -> (min: Iterator.Element, max: Iterator.Element)?
> }
> 
> extension Collection {
> /// Returns the index of the minimum element of `self`, using 
> /// `isOrderedBefore` to compare elements, or `nil` if the
> /// collection has no elements.
> func minIndex(@noescape isOrderedBefore isOrderedBefore: 
> (Iterator.Element, Iterator.Element) throws -> Bool
> ) rethrows -> Index?
> 
> /// Returns the index of the maximum element of `self`, using 

[swift-evolution] [Draft] Expanded min/max algorithms

[Nate Cook via swift-evolution]

Hello all,

Attached is a draft of a proposal to expand the min and max sequence APIs to 
better handle collections and to support future sorted sequences/collections. 
The proposal is in a gist here 
 and 
inlined below—would love to hear any comments or feedback before submitting the 
proposal.

Nate


Proposal: Expanded min/max algorithms
This proposal would expand on the min() and max() sequence methods to add 
methods that return the corresponding index for a collection, efficiently find 
the minimum and maximum elements or indices at the same time, and provide 
extension points for sorted collections to provide all these results more 
efficiently.

Related Bugs: SR-889  and SR-890 

Motivation
The Sequence protocol currently offers min() and max() methods that return the 
minimum and maximum elements of a sequence or collection. Unfortunately, there 
are applications where these methods do not provide enough flexibility to be 
useful.

First, if the user of a collection wants not just to get the minimum value but 
also to operate on it in some way (e.g., mutation or just accessing it multiple 
times), she would need the index of the minimum element. The current APIs don't 
support that, so she would need to write her own.

Second, the writer of a sorted collection is currently unable to provide 
efficient responses to the min() and max() methods when used in a generic 
context, even though these should be O(1) operations. Just like Set can respond 
quickly to contains(_:) even in a generic context, so too should new sorted 
collections be able to optimize their responses.

Finally, getting the minimum and maximum elements (or indices) of a collection 
or sequence currently requires calling both min() and max(). With two calls, 
every element is iterated and compared twice. When you need both results, 
finding both the minimum and the maximum at the same time is more efficient, 
requiring only a single pass and 25% fewer comparisons.

Proposed solution
This proposal has three parts:

Adding minIndex() and maxIndex() methods to Collection that return the index of 
the minimum and maximum elements, respectively.

let numbers = [30, 40, 10, 20, 60, 50]

if let i = numbers.minIndex() {
print("\(i): \(numbers[i])")   // 2: 10
}
Adding minmax() and minmaxIndices() methods to Sequence and Collection, 
respectively, to calculate the values (or indices) of the minimum and maximum 
elements simultaneously.

if let result = numbers.minmax() {
// result == (minimum: 10, maximum: 60)
// ...
}
if let i = numbers.minmaxIndices() {
// i == (minimum: 2, maximum: 4)
print("\(i.minimum): \(numbers[i.minimum])")
}
Adding customization points for sequences and collections that can offer more 
efficient results: _customMinComparableElement()/_customMaxComparableElement() 
for Sequence and 
_customIndexOfMinComparableElement()/_customIndexOfMaxComparableElement()for 
Collection.

Detailed design
The following methods would be added to the visible public APIs of Sequence and 
Collection as default implementations.

extension Sequence {
/// Returns the minimum and maximum values of `self`, using 
/// `isOrderedBefore` to compare elements, or `nil` if the sequence
/// has no elements.
func minmax(@noescape isOrderedBefore isOrderedBefore: 
(Iterator.Element, Iterator.Element) throws -> Bool
) rethrows -> (min: Iterator.Element, max: Iterator.Element)?
}

extension Sequence where Iterator.Element: Comparable {
/// Returns the minimum and maximum values of `self`, or `nil` 
/// if the sequence has no elements.
func minmax() -> (min: Iterator.Element, max: Iterator.Element)?
}

extension Collection {
/// Returns the index of the minimum element of `self`, using 
/// `isOrderedBefore` to compare elements, or `nil` if the
/// collection has no elements.
func minIndex(@noescape isOrderedBefore isOrderedBefore: 
(Iterator.Element, Iterator.Element) throws -> Bool
) rethrows -> Index?

/// Returns the index of the maximum element of `self`, using 
/// `isOrderedBefore` to compare elements, or `nil` if the
/// collection has no elements.
func maxIndex(@noescape isOrderedBefore isOrderedBefore: 
(Iterator.Element, Iterator.Element) throws -> Bool
) rethrows -> Index?

/// Returns the indices of the minimum and maximum elements of `self`, 
/// using `isOrderedBefore` to compare elements, or `nil` if the
/// collection has no elements.
func minmaxIndices(@noescape isOrderedBefore isOrderedBefore: 
(Iterator.Element, Iterator.Element) throws -> Bool
) rethrows -> (minIndex: Index, maxIndex: Index)?
}

extension Collection where Iterator.Element: Comparable {
/// Returns the index of the minimum element of `self`, o

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

[Brent Royal-Gordon via swift-evolution]

> With the above definition I would suggest a name change to entries, since a 
> Dictionary's keys are not necessarily numbers, hence enumerate is misleading. 
> 
> Nothing for Set since it isn't subscriptable. 

I think you're slightly confused. All Collections have an Index. Dictionary's 
Index is not its Key; it is an opaque type which references an entry in its 
internal table. Set also has an Index; again, it is an opaque type which 
references an entry in its internal table. Your `enumerate()` (or my 
`indexed()`) would return these opaque `Index`es on all of these types.

If you want Array to return `(Int, Element)`, Dictionary to return `(Key, 
Value)`, and Set to not have the operation at all, you're describing something 
ad-hoc and entirely disconnected from the Collection type.

-- 
Brent Royal-Gordon
Architechies

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

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

[Chris Lattner via swift-evolution]

> On Apr 16, 2016, at 8:48 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Apr 16, 2016, at 10:10 AM, Patrick Gili  
>> wrote:
>> 
>> As an alternative, could we require the parens on the return. For example:
>> 
>> (Int) -> (Float)
>> (String) -> ()
>> () -> ()
>> () -> (Double)
>> 
>> This looks cleaner, improves consistency, and simplifies the syntax (i.e., 
>> no need to remember when parens are necessary).
> 
> -1 from me.  And the rationale that I provided for this pitch doesn’t support 
> it: unlike arguments, return types really are just types, they don’t align 
> with other syntactic productions that have magic argument behavior.
> 
> I’ll write up a formal proposal for more discussion.

Here is the proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md

We can discuss this more when it is scheduled for review.

Thanks all,

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

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

[Chris Lattner via swift-evolution]

On Apr 15, 2016, at 5:04 PM, David Owens II  wrote:
> It’s weird to me that we can essentially erase the parameter names and 
> fallback to just the type signatures, but that can be a talk for another day.

I agree that that is odd.  In my opinion, it should be accepted to convert from 
a function type with labels to one without (or visa-versa), but not from a 
function type with one set of labels to one with another set.  This is a 
different topic though.

-Chris

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

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

[Chris Lattner via swift-evolution]

> On Apr 16, 2016, at 10:10 AM, Patrick Gili  
> wrote:
> 
> As an alternative, could we require the parens on the return. For example:
> 
> (Int) -> (Float)
> (String) -> ()
> () -> ()
> () -> (Double)
> 
> This looks cleaner, improves consistency, and simplifies the syntax (i.e., no 
> need to remember when parens are necessary).

-1 from me.  And the rationale that I provided for this pitch doesn’t support 
it: unlike arguments, return types really are just types, they don’t align with 
other syntactic productions that have magic argument behavior.

I’ll write up a formal proposal for more discussion.

-Chris

> 
> -Patrick
> 
>> On Apr 15, 2016, at 1:38 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Apr 15, 2016, at 5:11 AM, David Hart  wrote:
>>> 
>>> If the original rationale is gone, shouldn’t we also get rid of the empty 
>>> tuple-type and replace it by a full-blown Void instead of Void being a 
>>> typealis for the empty tuple?
>> 
>> This could be done, but it would make the language larger and less 
>> consistent.  It would require introducing a new concept (a first class Void 
>> type).  Further, at some point we may have the ability to define algorithms 
>> over arbitrary width tuples (e.g. perhaps like C++ variadic templates) and 
>> that benefits from having the empty tuple as a base case.
>> 
>> -Chris
>> 
>> 
>>> (Int) -> Float
>>> (String) -> Void
>>> () -> Void
>>> () -> Double
>>> 
>>> It looks more consistent to me.
>>> 
 On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution 
  wrote:
 
 We currently accept function type syntax without parentheses, like:
 
 Int -> Float
 String -> ()
 
 etc.  The original rationale aligned with the fact that we wanted to treat 
 all functions as taking a single parameter (which was often of tuple type) 
 and producing a tuple value (which was sometimes a tuple, in the case of 
 void and multiple return values).  However, we’ve long since moved on from 
 that early design point: there are a number of things that you can only do 
 in a parameter list now (varargs, default args, etc), implicit tuple splat 
 has been removed, and  the compiler has long ago stopped modeling function 
 parameters this way.  Beyond that, it eliminates one potential style war.
 
 Given all this, I think it makes sense to go for syntactic uniformity 
 between parameter list and function types, and just require parenthesis on 
 the argument list.  The types above can be trivially written as:
 
 (Int) -> Float
 (String) -> ()
 
 Thoughts?
 
 -Chris
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

[Howard Lovatt via swift-evolution]

For the Arithmetic protocol how about changing it to:

protocol Arithmetic {
func + (lhs: Self, rhs: Self) -> Self
mutating func += (rhs: Self) -> Self
...
}

That way naming issues are largely avoided, except for `mutating func
negate()` which has no operator and would therefore have to be a normal,
non-operator, func.

On Saturday, 16 April 2016, Nicola Salmoria via swift-evolution <
swift-evolution@swift.org> wrote:

> > Oh, a couple more things I just thought of:
> >
> > > public protocol Arithmetic: Equatable, IntegerLiteralConvertible {
> > If your goals include supporting complex numbers, how is
> IntegerLiteralConvertible going to fit in there?
> >
> > > /// Initialize to zero
> > > init()
> > 0 is valuable as the additive identity. Should there also be a way to
> get 1, the multiplicative identity? If you need both, should these be
> static properties instead of initializers?
>
> Interestingly, these two questions are related.
>
> If you expose the multiplicative identity, you automatically expose a
> natural way to convert from an integer N: just add `one` to itself N times.
> If N is negative, take the opposite.
>
> For complex numbers the multiplicative identity is 1 + 0i, so this means
> that Complex(N) = N + 0i.
>
> As an aside, a default generic implementation of IntegerLiteralConvertible
> would run in O(log N) steps, using the “double-and-add” algorithm:
>
> https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Double-and-add
> .
> Though I don’t think this is particularly useful for our use case :-)
>
> —
> Nicola
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


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

Re: [swift-evolution] [Accepted] SE-0048: Generic Type Aliases

[Chris Lattner via swift-evolution]

> On Apr 16, 2016, at 1:12 AM, Nicola Salmoria via swift-evolution 
>  wrote:
> 
>> Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
>> 
>> The review of SE-0048 “Generic Type aliases” ran from March 24…29, 2016. The 
>> proposal received overwhelmingly positive feedback and has now been 
>> implemented for Swift 3.
>> 
>> - Doug
> 
> Is this actually implemented fully?

No, I’m still working on it.

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

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

[Howard Lovatt via swift-evolution]

Re. OptionSetType

If you wrote:

enum Ex { case one, two, three }

The compiler could do:


   - struct Ex : OptionSetType
    {
   -   private let weight: Int 
   -   private init(_ weight: Int ) {
   self.weight = weight }
   -
   -   static let one = Ex(1)
   -   static let two = Ex(2)
   -   static let three = Ex(4)
   -   static let values: Ex = [one, two, three]
   - }


Plus the compiler would have to allow statics to have their type inferred,
i.e. you write .one and the compiler infers Ex.one.

This would allow set behaviour which I found very handy in Java.

PS Int only applicable for < 64 cases. Need BigInt for others.

On Saturday, 16 April 2016, Brent Royal-Gordon 
wrote:

> > I would suggest that ValuesEnumerable should expose allValues and the
> type of allValues should be a custom OptionSet implementation that iterates
> in declaration order.
>
> That would make sense if OptionSet were a generic type which took any
> integer-ish RawRepresentable (which I've advocated before, although I sort
> of understand why we haven't gone that route), but it isn't, so I don't
> think that makes a lot of sense for Swift.
>
> --
> Brent Royal-Gordon
> Architechies
>
>

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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Howard Lovatt via swift-evolution]

+1 for Scala's path dependent types.

On Saturday, 16 April 2016, Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Am 15.04.2016 um 23:19 schrieb Dmitri Gribenko via swift-evolution <
> swift-evolution@swift.org >:
> >
> > On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf  > wrote:
> >> On 2016-04-12 Dmitri Gribenko via swift-evolution wrote:
> >>>
> >>> Not even to mention that
> >>> indices are valid only in context of a particular collection instance,
> >>> so in this model you could validate an index against one collection
> >>> and use it with another one.
> >>
> >>
> >> The proposal requires Index values to be Comparable. Does that mean that
> >> indices from different collection instances should be comparable i.e.
> have a
> >> strict total order?
> >
> > No, comparing indices from unrelated instances produces unspecified
> > results (incl. traps).
>
> Path dependent types as used in Scala would allow making this distinction
> type safe (see http://docs.scala-lang.org/tutorials/tour/inner-classes or
> http://danielwestheide.com/blog/2013/02/13/the-neophytes-guide-to-scala-part-13-path-dependent-types.html)
> by allowing the index type to be rooted at the instance.
>
> Are there any plans to adding path dependent types to Swift?
>
> -Thorsten
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


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

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

[Howard Lovatt via swift-evolution]

I would suggest enumerate only for types that are subscriptable and that it
be defined as their (index, value) set that iterates in the collection's
indices order. IE:

for index in collection.indices {
let value = collection[index]
...
}

and

for (index, value) in collection.enumerate {
...
}

are equivalent.

With the above definition I would suggest a name change to entries, since a
Dictionary's keys are not necessarily numbers, hence enumerate is
misleading.

Nothing for Set since it isn't subscriptable.

On Saturday, 16 April 2016, Brent Royal-Gordon 
wrote:

> > I would suggest an alternative; changing Range so that it is indexed
> like an array, an Int from 0 to count - 1. Such that aRange[index] is
> defined as start + index * stride. This will eliminate the problems with
> enumerate. A Range's generic type would be constrained to be an Arithmetic
> type, see extended floating point proposal.
>
> That papers over the problem for Slice/Range specifically, but it doesn't
> fix it for types with non-integer indices, like Dictionary and Set.
> enumerate() is not meant to be used for the purpose to which it is usually
> put.



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

Re: [swift-evolution] SE-0031 and Swift 2

[Drew Crawford via swift-evolution]

My stuff is maintained by a single team.  My problem is that Swift 2 is too 
immature to be usable on Linux, while Swift 3 is considered not 
production-grade on iOS/OSX.  I have code that compiles for both platforms, and 
so it needs to support 2+3, 2 for Darwin and 3 for Linux.

I would really like to see a saner way to go about this than duplicating whole 
function definitions.  Maybe that solution is to backport the new syntax, or to 
forward-port the old syntax with a warning.



> On Apr 16, 2016, at 3:52 PM, Jonathan Tang  wrote:
> 
> FWIW the Python 3 migration found removal of old syntax and introduction of 
> new syntax in the same release to be hugely problematic, and ended up 
> back-porting a lot of Python 2 syntax features into 3.1 & 3.2 to ease the 
> transition.  The problem is that large codebases are very rarely controlled 
> by a single team, and each sub-library usually has their own schedule for 
> update, such that cutting over all at once is not possible.  The approach 
> usually needs to be
> 
> 1. Introduce the new syntax
> 2. Deprecate the old syntax, with fixits and strong warnings about when it'll 
> be removed.
> 3. Allow at least one version (and usually a couple) to pass as a transition.
> 4. Remove the old syntax.
> 
> Not sure how much of a problem this'll be for Swift, which has had some 
> pretty clear "things may break with Swift 3" warnings on it.  My own 
> organization is small, and can probably cut over all at once as long as 
> there's a migration tool.  But I've worked in big organizations where 
> upgrading would be a complete non-starter if there's no transitional syntax 
> that's compatible with both old and new compilers, and once Swift gets a 
> decent third-party library ecosystem it'd be impractical to ever upgrade 
> until library dependencies were upgraded, and it'd be impractical to upgrade 
> the libraries until all their clients had switched.  Deadlock. 
> 
> On Sat, Apr 16, 2016 at 3:55 AM, Drew Crawford via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Hello,
> 
> I'm writing to complain about SE-0031 and Swift 2 compatibility.  I 
> understand (and agree with!) the change, but the migration between now and 
> 2017 is annoying, hence my complaint.
> 
> In snapshot swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a, we started erroring on 
> the old syntax.  That means that this:
> 
> func foo(inout bar: Int) { }
> 
> is not legal Swift 3.
> 
> ...however, the new syntax:
> 
> func foo(bar: inout Int) { }
> 
> is not legal Swift 2.  This complicates compiling for both, which several of 
> my projects currently do.
> 
> /Further complicating matters/, Swift does not understand line-scoped ifdefs. 
>  So this:
> 
> #if swift(>=3.0)
> func foo(bar: inout Int) {
> #else
> func foo(inout bar: Int) {
> #endif
> //my
> //long
> //functon
> //definition
> }
> 
> Is not legal Swift.  The only way I know of is to say:
> 
> #if swift(>=3.0)
> func foo(bar: inout Int) {
> //my
> //long
> //functon
> //definition
> }
> #else
> func foo(inout bar: Int) {
> //my
> //long
> //functon
> //definition
> }
> #endif
> 
> which forces duplication of the entire function definition.
> 
> My suggestion would be one or more of the following:
> 
> 1.  Support both syntaxes in Swift 3 "trunk" (e.g. until Swift 3 is released).
> 2.  Backport the new syntax to Swift 2.2
> 3.  Consider allowing line-scoped ifdefs
> 
> Thanks for reading, and sorry to rain on a parade I largely think is Good For 
> Swift ™
> 
> Drew
> 
> ___
> 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] SE-0031 and Swift 2

[Jonathan Tang via swift-evolution]

FWIW the Python 3 migration found removal of old syntax and introduction of
new syntax in the same release to be hugely problematic, and ended up
back-porting a lot of Python 2 syntax features into 3.1 & 3.2 to ease the
transition.  The problem is that large codebases are very rarely controlled
by a single team, and each sub-library usually has their own schedule for
update, such that cutting over all at once is not possible.  The approach
usually needs to be

1. Introduce the new syntax
2. Deprecate the old syntax, with fixits and strong warnings about when
it'll be removed.
3. Allow at least one version (and usually a couple) to pass as a
transition.
4. Remove the old syntax.

Not sure how much of a problem this'll be for Swift, which has had some
pretty clear "things may break with Swift 3" warnings on it.  My own
organization is small, and can probably cut over all at once as long as
there's a migration tool.  But I've worked in big organizations where
upgrading would be a complete non-starter if there's no transitional syntax
that's compatible with both old and new compilers, and once Swift gets a
decent third-party library ecosystem it'd be impractical to ever upgrade
until library dependencies were upgraded, and it'd be impractical to
upgrade the libraries until all their clients had switched.  Deadlock.

On Sat, Apr 16, 2016 at 3:55 AM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello,
>
> I'm writing to complain about SE-0031 and Swift 2 compatibility.  I
> understand (and agree with!) the change, but the migration between now and
> 2017 is annoying, hence my complaint.
>
> In snapshot swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a, we started erroring
> on the old syntax.  That means that this:
>
> func foo(inout bar: Int) { }
>
> is not legal Swift 3.
>
> ...however, the new syntax:
>
> func foo(bar: inout Int) { }
>
> is not legal Swift 2.  This complicates compiling for both, which several
> of my projects currently do.
>
> /*Further complicating matters*/, Swift does not understand line-scoped
> ifdefs.  So this:
>
> #if swift(>=3.0)
> func foo(bar: inout Int) {
> #else
> func foo(inout bar: Int) {
> #endif
> //my
> //long
> //functon
> //definition
> }
>
> Is not legal Swift.  The only way I know of is to say:
>
> #if swift(>=3.0)
> func foo(bar: inout Int) {
> //my
> //long
> //functon
> //definition
> }
> #else
> func foo(inout bar: Int) {
> //my
> //long
> //functon
> //definition
> }
> #endif
>
> which forces duplication of the entire function definition.
>
> My suggestion would be one or more of the following:
>
> 1.  Support both syntaxes in Swift 3 "trunk" (e.g. until Swift 3 is
> released).
> 2.  Backport the new syntax to Swift 2.2
> 3.  Consider allowing line-scoped ifdefs
>
> Thanks for reading, and sorry to rain on a parade I largely think is Good
> For Swift ™
>
> Drew
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

[Patrick Gili via swift-evolution]

I have to agree with those that simply want enumerate() fixed. There are many 
modern languages that have a similar function, such as Ruby.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave via swift-evolution]

> On Apr 16, 2016, at 12:10 PM, Patrick Gili via swift-evolution 
>  wrote:
> 
> As an alternative, could we require the parens on the return. For example:
> 
> (Int) -> (Float)
> (String) -> ()
> () -> ()
> () -> (Double)
> 
> This looks cleaner, improves consistency, and simplifies the syntax (i.e., no 
> need to remember when parens are necessary).
> 
> -Patrick

I’m not sure it’s “cleaner” per se, but I agree with the rest. My earlier +1 
may have been premature…

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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Patrick Gili via swift-evolution]

> 
>   * What is your evaluation of the proposal?

1) I think eliminating intervals increases consistency and reduces confusion.

2) I really like the fact that this will make in-place index traversal methods 
public. It will reduce the amount of boilerplate for developers implementing 
new collections.

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

Yes.

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

Yes.

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

Most modern languages provide a sophisticated library supporting collections. I 
think this proposal is moving the Swift Foundation in the direction of the C++ 
STL and Boost libraries.

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

In-depth.

> 

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

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

[Patrick Gili via swift-evolution]

As an alternative, could we require the parens on the return. For example:

(Int) -> (Float)
(String) -> ()
() -> ()
() -> (Double)

This looks cleaner, improves consistency, and simplifies the syntax (i.e., no 
need to remember when parens are necessary).

-Patrick

> On Apr 15, 2016, at 1:38 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Apr 15, 2016, at 5:11 AM, David Hart  wrote:
>> 
>> If the original rationale is gone, shouldn’t we also get rid of the empty 
>> tuple-type and replace it by a full-blown Void instead of Void being a 
>> typealis for the empty tuple?
> 
> This could be done, but it would make the language larger and less 
> consistent.  It would require introducing a new concept (a first class Void 
> type).  Further, at some point we may have the ability to define algorithms 
> over arbitrary width tuples (e.g. perhaps like C++ variadic templates) and 
> that benefits from having the empty tuple as a base case.
> 
> -Chris
> 
> 
>> (Int) -> Float
>> (String) -> Void
>> () -> Void
>> () -> Double
>> 
>> It looks more consistent to me.
>> 
>>> On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> We currently accept function type syntax without parentheses, like:
>>> 
>>> Int -> Float
>>> String -> ()
>>> 
>>> etc.  The original rationale aligned with the fact that we wanted to treat 
>>> all functions as taking a single parameter (which was often of tuple type) 
>>> and producing a tuple value (which was sometimes a tuple, in the case of 
>>> void and multiple return values).  However, we’ve long since moved on from 
>>> that early design point: there are a number of things that you can only do 
>>> in a parameter list now (varargs, default args, etc), implicit tuple splat 
>>> has been removed, and  the compiler has long ago stopped modeling function 
>>> parameters this way.  Beyond that, it eliminates one potential style war.
>>> 
>>> Given all this, I think it makes sense to go for syntactic uniformity 
>>> between parameter list and function types, and just require parenthesis on 
>>> the argument list.  The types above can be trivially written as:
>>> 
>>> (Int) -> Float
>>> (String) -> ()
>>> 
>>> Thoughts?
>>> 
>>> -Chris
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Accepted] SE-0048: Generic Type Aliases

[James Richard via swift-evolution]

I believe he means it has been merged to master, and will be in the next 
snapshot.

Sent from my iPad

On Apr 16, 2016, at 1:12 AM, Nicola Salmoria via swift-evolution 
 wrote:

>> Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
>> 
>> The review of SE-0048 “Generic Type aliases” ran from March 24…29, 2016. The 
>> proposal received overwhelmingly positive feedback and has now been 
>> implemented for Swift 3.
>> 
>> - Doug
> 
> Is this actually implemented fully?
> 
> The constraints on the typealias type don’t seem to work in the latest 
> development snapshot (2016-04-12a):
> 
> typealias StringDict = Dictionary // error: type 'T' does not 
> conform to protocol 'Hashable'
> typealias StringDict = Dictionary   // error: type 
> parameters may not be constrained in typealias argument list
> 
> —
> Nicola
> 
> ___
> 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] [Pitch] Unifying init parameters with properties

[Jonathan Hull via swift-evolution]

Since we know the types of the properties, how about we replace the type in the 
signature with either an indication that the property should be automatically 
set, or better yet, the property which should be set:

class Foo
{
let foo : String
let bar : String
let barCount : Int
let baz : Int

init(foo: self.foo, bar: self.bar, baz: self.baz)
{
self.barCount = bar.characters.count
} 
}

That way you don’t always have to have the init’s parameter names match the 
names of the properties they set (even though they often would).  We could also 
allow a leading dot as a shorthand for ‘self.’

init(foo: .foo, bar: .bar, baz: .baz)
 
I think I like explicit ‘self.’ better, but that may just be my preference.  In 
either case, the generated interface would show the actual type.

// init(foo: String, bar: String, baz: Int)

Thanks,
Jon

> This is a common pattern for initialisers at the moment:
> 
> class Foo
> 
> {
> 
> let foo : String
> 
> let bar : String
> 
> let barCount : Int
> 
> let baz : Int
> 
> 
> init(foo: String, bar: String, baz: Int)
> 
> {
> 
> self.foo = foo
> 
> self.bar = bar
> 
> self.baz = baz
> 
> barCount = bar.characters.count
> 
> }
> 
> }
> 
> This involves a lot of using 'self.'. For those who prefer not to use
> 'self.' explicitly everywhere, this is probably the main place it gets
> used. It's a lot of boilerplate code.
> 
> How would it be if, like default variables, we could pack some of that
> information into the argument tuple, and unify parameters with properties
> immediately?
> 
> class Foo
> 
> {
> 
> let foo : String
> 
> let bar : String
> 
> let barCount : Int
> 
> let baz : Int
> 
> 
> init(self.foo: String, self.bar: String, self.baz: Int)
> 
> {
> 
> barCount = bar.characters.count
> 
> }
> 
> }
> 
> Less boilerplate, more focus on the properties which need to be generated.
> 
> Thoughts?

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

Re: [swift-evolution] [SR-933] Rename flatten to flattened

[Patrick Smith via swift-evolution]

Yes, I agree. I think in the guidelines should be a recommendation for mutating 
methods are preferred, when nonmutating are preferred, and when to have both. 
If performance is a key goal of Swift, so much that it influences API design, 
then some details should be part of the guidelines also.
Patrick




On Sat, Apr 16, 2016 at 3:56 AM -0700, "David Rönnqvist" 
 wrote:










By “the big three”, are you referring to only the naming of map, filter, and 
reduce? 
I would also like to see a formal proposal along these lines, and possibly 
more. 
I also feel that the `inPlace` suffix was very clear (most important) and very 
much liked that it made the immutable version the default (less important). It 
manages to describe the distinction between `union`/`unionInPlace` and 
`sort`/`sortInPlace` in the name itself. To me, the `ed`/`ing` difference is 
much more subtle and favors people who are familiar with English grammar. One 
can argue that `sort` is both imperative and functional, and that because of 
[either side] the default should be [mutable/immutable]. Both arguments are 
valid. 
- David
On 15 Apr 2016, at 18:31, Erica Sadun via swift-evolution 
 wrote:

On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution 
 wrote:
I've already expressed these concerns, but nobody noticed, apparently. Here is 
it:
I think current -ed/-ing convention is ugly. It breaks syntactic correctness, 
experience from other languages, mathematical notation and functional idioms.

`InPlace` suffix was so far more correct in these terms. We can make anything a 
convention, but should we?
I liked the proposal about new naming conventions, but overlooked this change.

Many people will agree with me. This still can be reviewed until Swift 3.
If so, I will create a proposal to correct "the big three" in this.

What do you think?
I would like to see a formal proposal along these lines. My other suggestions 
are here.
-- E

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





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

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

[plx via swift-evolution]

> On Apr 15, 2016, at 9:00 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> This discussion is about a proposal for API to enumerate/count all possible 
> values of a type, particularly enums. The goal is to address potential issues 
> with an old proposal, so it can go up for review soon.
> 
> Core Team / Standard Library Team feedback would be particularly welcome 
> here, because we want this feature to mesh well with the goals & future 
> directions that are already in mind for Swift. If any details the core team 
> would like to see are missing from the proposal, please let us know now.
> 
> Background reading:
> 
> • 2015-12-08: "List of all Enum values (for simple enums)" — 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/10064 
> 
> • 2015-12-21: "Proposal: Enum 'count' functionality" 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/644 
> 
> • 2016-01-17: "Draft Proposal: count property for enum types" 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/3678 
> 
> • 2016-01-18: "Pre-proposal: CaseEnumerable protocol (derived collection 
> of enum cases)" at 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/3701 
> 
> • 2016-01-20: My subsequent proposal PR #114: 
> https://github.com/apple/swift-evolution/pull/114 
> 
> 
> A lot has happened since then:
> 
> • 2016-03-03: "[Manifesto] Completing Generics" 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/8484 
> 
> • 2016-03-03: "[Accepted with modifications] SE-0023 API Design 
> Guidelines" http://thread.gmane.org/gmane.comp.lang.swift.evolution/8585 
>  & 
> http://apple.github.io/swift-internals/api-design-guidelines/ 
> 
> • 2016-03-09: Brent's proposal PR #199: 
> https://github.com/apple/swift-evolution/pull/199 
> 
> 
> Brent brought up some great points in his proposal, but ultimately closed the 
> PR in anticipation of further discussion. I'm sorry I haven't had much time 
> to put into this until now, but I'd like us to get the discussion going again.
> 
> I believe the community is in agreement about the following:
> 
> • The "allValues" behavior should be provided by conformance to some 
> protocol, named ValueEnumerable or ValuesEnumerable or similar.
> • The compiler should derive an allValues implementation for "simple" 
> enums (those without associated values).
> 
> There are a couple things which we must still decide:
> 
> ### Should the ValueEnumerable protocol expose the allValues property, or 
> should it be an empty protocol like ErrorType (ErrorProtocol)? If exposed, 
> what is its type?

# General Remarks

My 2c is that if this is to go in the standard library, it should be done 
“right”, which would be more like this version of it:

protocol ValueEnumerable {
  associatedtype ValueCollection : Collection where 
ValueCollection.Iterator.Element == Self
  static var allValues: ValueCollection
}

…and that this concept should simply *wait* for that feature to be available 
before going into the standard library. 

The reason I say this is simply b/c it sounds like this proposal wants to be 
able to support more than simple enumerations, in which case having some 
flexibility in the representation seems appropriate. Consider e.g.:

  struct AxisPolicy3D> {
var x: Policy
var y: Policy
var z: Policy
  }

  extension AxisPolicy3D : ValueEnumerable {

static let allValues: ValueCollection = 
product(Policy.allValues,Policy.allValues,Policy.allValues).lazy.map() { 
(x,y,z) 
in
AxisPolicy3D(x: x, y: y, z: z)
}

  }

…and similar, wherein the cost of *requiring* an array here could become rather 
large.

But I have a couple general concerns here:

# Resiliency 

My understanding is that the design for resiliency vis-a-vis enumerations is 
meant to allow enumerations to have cases added in future revisions (and 
perhaps also private cases? I didn’t follow resiliency closely). 

If that’s right, and this protocol is supposed to go into the standard library, 
it might also need to address such issues. I have no help to offer and would 
love to be wrong about this point.

# Scope (or: Beyond Simple Enumerations?)

On the one hand, I don’t see any reason *not* to design the protocol so that it 
*could* be adopted by types other than simple enumerations. 

On the other hand, I think the value of having this in place for 
simple-enumerations is huge, and I’m more than a bit 

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

[Thorsten Seitz via swift-evolution]

> Am 12.04.2016 um 01:01 schrieb Yuta Koshizawa :
> 
> Hi.
> 
> Decoding a JSON is just an example. As I replied to Thorsten, we can
> think about various cases we want to unwrap multiple optionals at
> once.
> 
> This is another example (with the notation `|?` and the postfix
> version I proposed instead of the infix `???`).
> 
> ```
> do {
>  let sum = try Int(aString)|? + Int(bString)|?
> } catch _ {
>  // Error handling
> }
> ```
> 
> With optional binding, we need to write something like the following.
> It needs additional assignments (bindings) to `a` and `b`.
> 
> ```
> if let a = Int(aString), b = Int(bString) {
>  let sum = a + b
> } else {
>  // Error handling
> }
> ```

Actually I find this much more readable than the version above which mixes 
error handling (|?) and the business logic (a + b), making the business logic 
more difficult to understand. Using meaningful names instead of `a` and `b` 
will increase readability even more.

-Thorsten

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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Thorsten Seitz via swift-evolution]

> Am 15.04.2016 um 23:19 schrieb Dmitri Gribenko via swift-evolution 
> :
> 
> On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf  wrote:
>> On 2016-04-12 Dmitri Gribenko via swift-evolution wrote:
>>> 
>>> Not even to mention that
>>> indices are valid only in context of a particular collection instance,
>>> so in this model you could validate an index against one collection
>>> and use it with another one.
>> 
>> 
>> The proposal requires Index values to be Comparable. Does that mean that
>> indices from different collection instances should be comparable i.e. have a
>> strict total order?
> 
> No, comparing indices from unrelated instances produces unspecified
> results (incl. traps).

Path dependent types as used in Scala would allow making this distinction type 
safe (see http://docs.scala-lang.org/tutorials/tour/inner-classes or 
http://danielwestheide.com/blog/2013/02/13/the-neophytes-guide-to-scala-part-13-path-dependent-types.html)
 by allowing the index type to be rooted at the instance.

Are there any plans to adding path dependent types to Swift?

-Thorsten

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

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

[Brent Royal-Gordon via swift-evolution]

> • The "allValues" behavior should be provided by conformance to some 
> protocol, named ValueEnumerable or ValuesEnumerable or similar.
> • The compiler should derive an allValues implementation for "simple" 
> enums (those without associated values).

Agreed on my part.

(I favor "Values" because "Value" in the singular implies to me that you can 
take a single value and enumerate it somehow, which is not what I have in mind.)

> If allValues were exposed as part of the protocol, then the generic 
> constraint  could be used meaningfully, i.e. you could 
> write/use "T.allValues".
> 
> On the other hand, the limitations of the current generics system don't allow 
> "associatedtype ValueCollection: Collection where 
> ValueCollection.Iterator.Element == Self". Doug's Completing Generics 
> manifesto included "Arbitrary requirements in protocols", under the category 
> of "Minor extensions", which would remove this limitation. If this gets 
> implemented, I think it makes a lot of sense to use it here.

Yes. I see some metaprogramming potential in being able to pass just a type and 
enumerate its values. For instance, you could say how far "through" a type that 
particular value lies, using nothing but an instance of it.

> Until then, though, we'd have to pick a concrete type for the collection. 
> Brent proposed that it be an Array, "static var allValues: [Self]".
> 
> The biggest reason I didn't expose allValues on the protocol was that I 
> figured we'd want to allow for efficient implementations which wouldn't 
> require allocating storage for *all* the values (just the endpoints, for 
> instance), but could still count and iterate over them.

If the Array limitation is truly going to be temporary, I don't think the need 
for storage is a serious long-term problem. Especially before we start getting 
fancy and supporting `ValueEnumerable` associated values, each `allValues` 
array is going to be small.

(However, see below for another path forward which would allow a much smaller 
instance.)

> Another question on the subject of exposing the property as a protocol 
> requirement: What should the diagnostics look like if it's missing? Maybe 
> something like this:
> 
> struct MyType: ValueEnumerable { }
> // error: type 'MyType' does not conform to protocol 'ValueEnumerable'
> // note: protocol requires property 'allValues' with type '[MyType]'
> // note: implementation of allValues cannot be automatically derived for 
> a non-enum type

If Swift cannot automatically derive an implementation for a particular type, I 
think having a diagnostic stating that, and preferably saying why, would be a 
great idea.

> ### Should allValues implementations be derived for Comparable enums? What if 
> the sorted order does/doesn't match the source order?
> 
> Brent has suggested the semantics of allValues should be such that for 
> Comparable types, allValues is guaranteed to be ordered. If that were the 
> case, we might not want to require the compiler to derive a ValueEnumerable 
> implementation, since the source order may not match the Comparable-sorted 
> order, and verifying this could overly complicate things. (I think I'm in 
> agreement here: having the values be ordered is a good implementation of the 
> principle of least surprise.)

With the impending introduction of a `Comparable` requirement on collection 
indices, we now have a second good reason for this: the values themselves are 
good candidates to index into the `allValues` collection, and they will need to 
be `Comparable`.

Incidentally, one open question is whether enums with raw values should be 
compared in source order or in raw value order. In other words, in:

enum Foo: ValuesEnumerable {
case bar = 2
case baz = 1
}

Is `Foo.allValues` equivalent to `[bar, baz]` or `[baz, bar]`? I'm not certain 
we can always reliably sort raw values at compile time; `String` is 
particularly worrisome because sort order tends to depend on tables built into 
the OS, but even integer literals are suspect when you consider that this 
feature can be used to initialize *any* `IntegerLiteralConvertible` type (or 
`StringLiteralConvertible`, or I believe `FloatLiteralConvertible` as well). 
Analyzing a raw value's sort order eventually becomes equivalent to analyzing a 
custom Comparable implementation.

* * *

However, the new Collection proposal (SE-0065, 
https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md)
 has actually given me an interesting idea about how to build this feature out 
of smaller pieces.

Suppose we introduce a `ValuesCountable` (or maybe just `Countable`) protocol 
like this:

protocol ValuesCountable: Strideable /* implies Comparable and 
Equatable */ {
associatedtype Stride: SignedInteger
static var allValues: CountableClosedRange { get }
}

Swift already synthesizes Equatabl

Re: [swift-evolution] [SR-933] Rename flatten to flattened

[David Rönnqvist via swift-evolution]

By “the big three”, are you referring to only the naming of map, filter, and 
reduce? 

I would also like to see a formal proposal along these lines, and possibly 
more. 

I also feel that the `inPlace` suffix was very clear (most important) and very 
much liked that it made the immutable version the default (less important). It 
manages to describe the distinction between `union`/`unionInPlace` and 
`sort`/`sortInPlace` in the name itself. To me, the `ed`/`ing` difference is 
much more subtle and favors people who are familiar with English grammar. One 
can argue that `sort` is both imperative and functional, and that because of 
[either side] the default should be [mutable/immutable]. Both arguments are 
valid. 

- David

> On 15 Apr 2016, at 18:31, Erica Sadun via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I've already expressed these concerns, but nobody noticed, apparently. Here 
>> is it:
>> 
>> I think current -ed/-ing convention is ugly. It breaks syntactic 
>> correctness, experience from other languages, mathematical notation and 
>> functional idioms.
>> 
>> `InPlace` suffix was so far more correct in these terms. We can make 
>> anything a convention, but should we?
>> I liked the proposal about new naming conventions, but overlooked this 
>> change.
>> 
>> Many people will agree with me. This still can be reviewed until Swift 3.
>> If so, I will create a proposal to correct "the big three" in this.
>> 
>> What do you think?
> 
> I would like to see a formal proposal along these lines. My other suggestions 
> are here 
> .
> 
> -- E
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] SE-0031 and Swift 2

[Drew Crawford via swift-evolution]

Hello,

I'm writing to complain about SE-0031 and Swift 2 compatibility.  I understand 
(and agree with!) the change, but the migration between now and 2017 is 
annoying, hence my complaint.

In snapshot swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a, we started erroring on the 
old syntax.  That means that this:

func foo(inout bar: Int) { }

is not legal Swift 3.

...however, the new syntax:

func foo(bar: inout Int) { }

is not legal Swift 2.  This complicates compiling for both, which several of my 
projects currently do.

/Further complicating matters/, Swift does not understand line-scoped ifdefs.  
So this:

#if swift(>=3.0)
func foo(bar: inout Int) {
#else
func foo(inout bar: Int) {
#endif
//my
//long
//functon
//definition
}

Is not legal Swift.  The only way I know of is to say:

#if swift(>=3.0)
func foo(bar: inout Int) {
//my
//long
//functon
//definition
}
#else
func foo(inout bar: Int) {
//my
//long
//functon
//definition
}
#endif

which forces duplication of the entire function definition.

My suggestion would be one or more of the following:

1.  Support both syntaxes in Swift 3 "trunk" (e.g. until Swift 3 is released).
2.  Backport the new syntax to Swift 2.2
3.  Consider allowing line-scoped ifdefs

Thanks for reading, and sorry to rain on a parade I largely think is Good For 
Swift ™

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

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

[Nicola Salmoria via swift-evolution]

> Oh, a couple more things I just thought of:
> 
> > public protocol Arithmetic: Equatable, IntegerLiteralConvertible {
> If your goals include supporting complex numbers, how is 
> IntegerLiteralConvertible going to fit in there?
> 
> > /// Initialize to zero
> > init()
> 0 is valuable as the additive identity. Should there also be a way to get 1, 
> the multiplicative identity? If you need both, should these be static 
> properties instead of initializers?

Interestingly, these two questions are related.

If you expose the multiplicative identity, you automatically expose a natural 
way to convert from an integer N: just add `one` to itself N times.
If N is negative, take the opposite.

For complex numbers the multiplicative identity is 1 + 0i, so this means that 
Complex(N) = N + 0i.

As an aside, a default generic implementation of IntegerLiteralConvertible 
would run in O(log N) steps, using the “double-and-add” algorithm:
https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Double-and-add.
Though I don’t think this is particularly useful for our use case :-)

—
Nicola

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

[swift-evolution] [Accepted] SE-0048: Generic Type Aliases

[Nicola Salmoria via swift-evolution]

> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
> 
> The review of SE-0048 “Generic Type aliases” ran from March 24…29, 2016. The 
> proposal received overwhelmingly positive feedback and has now been 
> implemented for Swift 3.
> 
> - Doug

Is this actually implemented fully?

The constraints on the typealias type don’t seem to work in the latest 
development snapshot (2016-04-12a):

typealias StringDict = Dictionary // error: type 'T' does not 
conform to protocol 'Hashable'
typealias StringDict = Dictionary   // error: type 
parameters may not be constrained in typealias argument list

—
Nicola

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

Re: [swift-evolution] Open Source version of "The Swift Programming Language"

[Hugues Bernet-Rollande via swift-evolution]

Yes, switching easily between language version outside of Github would
definitely be sweet.

The docs could even be organized as one or multiple playgrounds with pages.
Allowing to see the results live and play with it.

The learning by playing with it strategy of playground seem definitely
adapted to this.

Hugues

On Sat, Apr 16, 2016 at 03:18 Andrew Bennett  wrote:

> I think this is a great idea.
>
> I'm not sure how big a task it is to open source the current system.
> Hopefully it's easy for Apple to extract the content, convert it to
> markdown (if needed), and allow it to be updated from a git repo. It would
> be great if the website allowed you to browse tagged release versions
> (without having to go to github).
>
>
> On Sat, Apr 16, 2016 at 1:40 AM, Hugues Bernet-Rollande via
> swift-evolution  wrote:
>
>> Hi,
>>
>> Not sure this request fit the swift evolution mailing list, but it would
>> be great to have an open source (GitHub) version of the programming
>> language guide (
>> https://swift.org/documentation/#the-swift-programming-language) in
>> order to suggest edit regarding validated evolution and/or edit on the
>> current version.
>>
>> Using branches matching evolution named could ease doc update and tag to
>> identify specific version evolution.
>>
>> It will also facilitate any translation by homogenizing the guide
>> structure, like the ongoing chinese translation (
>> https://github.com/numb/the-swift-programming-language-in-chinese).
>>
>> Markdown seem to be a good choice for the actual content, and folder
>> structure for the chapter.
>>
>> It will also be a blast to be able to refer to some docs specific part
>> (via GitHub line selection feature) from others online resources (Stack
>> Overflow, ...).
>>
>> Happy to kickstart the project if Apple don't want to own it, but still
>> think there is a benefits for the community.
>>
>> Cheers,
>>
>> Hugues
>>
>>
>> Hugues BERNET-ROLLANDE
>>
>>
>> --
>>
>> hug...@xdev.fr
>>
>> http://www.xdev.fr
>>
>> http://www.linkedin.com/in/huguesbr
>>
>> ___
>> 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