Re: [swift-evolution] Introduction of OrderedSet

[Remy Demarest via swift-evolution]

+1 for ordered set and dictionary, and please add ordered dictionary in ObjC as 
well.

Envoyé de mon iPhone

> Le 9 juin 2017 à 03:11, Robert Bennett via swift-evolution 
>  a écrit :
> 
> +1, and would also like to see OrderedDictionary as well.
> 
>> On Jun 9, 2017, at 12:50 AM, Jeff Kelley via swift-evolution 
>>  wrote:
>> 
>> I would be in favor of it; there have been a few times (including Core Data, 
>> as you mentioned) where I would have used it had it been available.
>> 
>> 
>> Jeff Kelley
>> 
>> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
>> 
>>> On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> in the past there have been a few requests for an OrderedSet implementation 
>>> in Swift. In the proposal 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>>  was mentioned that the OrderedSet will be considered for the feature.
>>> 
>>> However, since then there were a few discussions on OrderedSet but it 
>>> doesn’t get much attention and there wasn’t any comment about it from the 
>>> swift team.
>>> 
>>> I want to bring up some points, why an OrderedSet is needed in the base 
>>> library.
>>> 
>>> 1. CoreData is probably the most obvious place where people would use an 
>>> ordered set. Especially when working with large amounts of data, presorting 
>>> can save a lot of time and battery life. If a bridgeable ordered set was 
>>> part of the standard library we could use a ordered set in swift without 
>>> having to use the NSOrderedSet from objective c. Which would be pretty nice 
>>> in my opinion. Even when using a NSOrderedSet we couldn’t have a generic 
>>> version of it.
>>> 
>>> 2. A shared datamodel between App and Server. One main advantage of having 
>>> web servers written in Swift is that we can share code between the server 
>>> and the app. For servers performance does matter a lot, since they are 
>>> usually working with much more data than apps. Databases are represented as 
>>> sets and fetching sorted data from the database can be represented as an 
>>> ordered set. However, since we don’t have ordered sets we have to choose 
>>> either a normal set or an array. Sets don’t have an order and arrays can 
>>> contain the same object multiple times, which makes them both a less 
>>> suitable choice.
>>> 
>>> 3. Swift has the potential to be used for education. There is a lot of 
>>> support, for example the playground app on iPad. When it comes to the 
>>> theory behind data structures and algorithms or to the theory of 
>>> computation a defined order plays an important role.
>>> 
>>> The biggest issue is that we always have to copy data from a set into an 
>>> array to have it in a sorted order with losing the safety of uniqueness. 
>>> Which is not suitable for a safe and performance oriented programming 
>>> language at all.
>>> 
>>> Last but not least, it fits in the goals of Swift 4 stage 2 and an ordered 
>>> set can be found in other popular programming languages, too.
>>> 
>>> What do you think?
>>> 
>>> Best regards,
>>> 
>>> Maik
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

[Remy Demarest via swift-evolution]

This is a great feature, and this is something that would allow the execution 
of multiple case statements that fallthrough does not currently allow. For 
example in today's world this is not allowed:

func blah(point: CGPoint) {
switch (point.x, point.y) {
case (let x, _) where x > 10:
print("\(x)")
fallthrough // error 'fallthrough' cannot transfer control to a case 
label that declares variables
case (_, let y) where y > 10:
print("\(y)")
case (let x, let y) where x <= 10 && y <= 10:
print("the point is too close from the border")
}
}

Using continue as proposed by erica would allow both patterns at the top to be 
evaluated and have the ability to check x and y independently.

Also this raises in my opinion an interesting point. I think along this 
proposal it would be great to have another type of case that would only run if 
no other pattern could be recognized. I'm not sure how to call it though.


> Le 10 juil. 2016 à 19:27, Erica Sadun via swift-evolution 
>  a écrit :
> 
> A quick pitch to introduce `continue` to switch statements. This would be 
> additive and could not be considered for Swift 3.
> 
> -- E
> 
> Pitch: Introduce continue to Switch Statements
> 
>  
> Introduction
> 
> This pitch completes the switch statement's control flow transfer suite by 
> introducing continue. Doing so provides functionality that a large portion of 
> newer developers expect from (but do not get from) fallthrough.
> 
>  
> Motivation
> 
> Swift's fallthrough statement means "continue by executing the code defined 
> in the next case clause". It has at least one solid use-case, which is 
> demonstrated in this example 
> 
> Swift Evolution discussed removing fallthrough on-list in early December 
>  
> We came to the consensus that fallthroughoffers sufficient utility to retain 
> the feature in the language:
> 
>  
> The
>  Problem with Fallthrough.
> 
> In Swift, fallthrough does not mean: "execute this case and then continue 
> pattern matching", which is what many naive users expect. Given the following 
> code where x is 5, they anticipate the function to print "5" and then 
> "anything else". This is wrong. Swift prints "5" and then "6".
> 
> func test(x : Int) {
> switch x {
> case 5:
> print("5")
> fallthrough
> case 6:
> print("6")
> default:
> print("anything else")
> }
> }
> Fallthrough is better suited for situations like the following:
> 
> case simple where even more subconditions hold: ... do complex things ...; 
> fallthrough
> case simple where subconditions hold: ... do other things ...; fallthrough
> case simple: ... do base things ...
> This example produces a sieve where the most restrictive conditions execute 
> specialized code and then execute code for less restrictive conditions.
> 
> Fallthrough cannot be used for situations like the following example:
> 
> case specialized situation 1: ... code specific to situation 1 ...; 
> fallthrough
> case specialized situation 2: ... code specific to situation 2 ...; 
> fallthrough
> case specialized situation 3: ... code specific to situation 3 ...; 
> fallthrough
> case general: ... general code applicable as well to the three specialized 
> situations ...
> Those coming from C-like languages might have the insight to expect (wrongly, 
> it should be noted) "5", then "6", then "anything else", which is what you'd 
> get with the following flawed C-ish code, where case statements are missing 
> break.
> 
> int x = 5;
> switch (x) {
> case 5: NSLog(@"5"); // no break;
> case 6: NSLog(@"6"); // no break;
> default: NSLog(@"anything else");
> }
> Swift-style switch statements are more powerful and general than C-style 
> switch statements. While I do not endorse C-style switch statements, I do 
> think there's a case to be made for continue, which would mean "continue 
> pattern matching". It would look like this:
> 
> case specialized situation 1: ... code specific to situation 1 ...; continue
> case specialized situation 2: ... code specific to situation 2 ...; continue
> case specialized situation 3: ... code specific to situation 3 ...; continue
> case general: ... general code applicable as well to the three specialized 
> situations ...
> In this example, code that matched general might execute any of the three 
> specialized subconditions as well but would not have to fall through each 
> case. So if a pattern matched scenarios 1 and 3, it would execute those cases 
> and the general case, but not scenario 2.
> 
>  
> 

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[Remy Demarest via swift-evolution]

We don't seem to have a rounded() function either as part of FloatingPoint, we 
should probably have these methods in the end:

func rounded() -> Self
func rounded(withPrecision: Int) -> Self

Along with the 4 other methods proposed below.

> Le 25 juin 2016 à 11:55, Haravikk via swift-evolution 
>  a écrit :
> 
> 
>> On 25 Jun 2016, at 11:06, Karl via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> floor() and ceil(), exactly like C. ceiling() is more descriptive and is a 
>> mathematical term of art .
>> nextIntegralUp() and nextIntegralDown() are more descriptive still, but 
>> possibly misleading as (4.0).nextIntegralUp() == 4.0
> I'm in favour of these capabilities being there, but in terms of naming I've 
> often wondered why it can't just be part of a rounding group of methods like 
> so:
> 
>   func roundedUp() -> Self { … }
>   func roundedUp(withPrecision:Int) -> Self { … }
>   func roundedDown() -> Self { … }
>   func roundedDown(withPrecision:Int) -> Self { … }
> 
> Since the methods with implied precision of zero are equivalent to floor and 
> ceiling surely? I know floor and ceiling are pretty common terms, but they're 
> just a form rounding when it comes down to it.
> ___
> 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-0104: Protocol-oriented integers

[Remy Demarest via swift-evolution]

I would also like to know why bit shifting and bit-wise and, or and xor 
operations are limited to FixedWidthInteger. I would think that a 
variable-length integer would be able to handle these operations in a 
predictable way consistent with the protocol. Wouldn't it?

> Le 22 juin 2016 à 23:23, Félix Cloutier via swift-evolution 
>  a écrit :
> 
> Do we lose the ability to create a signed integer from an unsigned bit 
> pattern?
> 
> Is there a way to get an optional initializer that returns `nil` if the 
> operand can't be represented?
> 
> What is the cost of heterogeneous comparison?
> 
> Félix
> 
>> Le 22 juin 2016 à 22:42:00, David Waite via swift-evolution 
>>  a écrit :
>> 
>> In addition to the technical review, I would like to point out that the 
>> definition of Arithmetic appears to be missing some underscores in 
>> add/adding/subtract/subtracting
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>> 
>>> * What is your evaluation of the proposal?
>> 
>> I’m so glad this work is being done!
>> 
>> For Integer, does the presence of signBit indicate an expectation that 
>> signed Integers will have a two's complement representation?
>> 
>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what 
>> situations would you have an overflow? I could only come up with something 
>> like Int.min.dividedWithOverflow(-1).
>> 
>>> * Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> Yes, oh yes.
>> 
>>> * Does this proposal fit well with the feel and direction of Swift?
>> 
>> It looks like a significant improvement. 
>> 
>>> 
>>> * How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> 
>> I combed the proposal for questions, although most were answered by the time 
>> I hit the end.
>> 
>> -DW
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] [swigt-evolution] [Pitch] Make NSOrderedSet behave like any other collections from Foundation

[Remy Demarest via swift-evolution]

Hello everyone,

Unlike its companion collections like NSArray, NSDictionary, and NSSet, 
NSOrdered is still a class rather than a struct and has a subclass that is 
still NSMutableOrderedSet. This should probably receive the same treatment as 
the other classes, namely:

- Use value semantic
- Use generics
- Keep the original NSOrderedSet class and its subclass NSMutableOrderedSet and 
bridge the two.

struct OrderedSet : SetAlgebra, Hashable, Collection, 
ArrayLiteralConvertible

This would add an ordered set type to Swift and fits nicely into the existing 
set of collections and classes moved from Foundation.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Remy Demarest via swift-evolution]

> Le 06 janv. 2016 à 22:03, Paul Cantrell via swift-evolution 
>  a écrit :
> 
> 
>> On Jan 6, 2016, at 2:56 PM, Loïc Lecrenier  wrote:
>> 
>>> Perhaps keyword capitalization conventions deserve some attention across 
>>> the board.
>> 
>> I thought the rules were:
>> - property/method: lowerCamelCase
>> - language keyword: lowercase
>> 
>> I consider 
>> - dynamicType as a property
>> - didSet, willSet, deinit as methods.
>> - typealias, fallthrough as language keywords
> 
> Those are all language keywords.
> 
> Complete list here: 
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/doc/uid/TP40014097-CH30-ID413
> 
> P

I think he was talking about how those keywords were used in the language. 
However, to me it just looks like post-hoc rationalization.

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



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