[swift-corelibs-dev] Proposal: Improve Import of Scanner APIs into Swift 3

[Oliver Drobnik via swift-corelibs-dev]

Earlier I posted this proposal to the Swift Evolution Mailing list. Then I 
looked at the NSScanner implementation in core libs and found experimental API 
using the return value to for returning the scanned results. See my comments on 
that below:


—

Working on a function for Foundation’s Scanner I stumbled on this LLVM crash: 
https://bugs.swift.org/browse/SR-3295 

This got me thinking about a workaround and I would like to prose this:

When importing Foundation into Swift 3, all 

AutoreleasingUnsafeMutablePointer?

should instead be exposed as simple:

inout T?

e.g.

open func scanString(_ string: String, into result: 
AutoreleasingUnsafeMutablePointer?) -> Bool

would become

open func scanString(_ string: String, into result: inout String?) -> Bool


The call would stay exactly the same for normal use cases where you specify a 
receiving variable:

var string: String?
scanString("=", into: &string)

because inout parameters require a &


for the use case where you don’t require a receiving parameter, a second method 
without result parameter would be generated:

open func scanString(_ string: String) -> Bool

This is necessary because you cannot specify nil or an immutable value for an 
inout parameter. 


A fixit/migration would change calls to

scanString(“foo", into result: nil)

into

scanString(“foo")


The normal call with receiving variable would stay the same. But the case 
without return would become more concise.

What do you think?

kind regards
Oliver Drobnik

—

The new experimental API does not consider the situation that one might just 
want to scan a token in a long string and since I know what I am scanning I 
don’t care about the result. For example in my scanning I would like to 
processed if I hit a “foo“ … 

The experimental API would force me to do this:

if let _ = scanString(“foo“) { }

My proposal is more elegant:

if scanString(“foo”) {}

And if you do lots and lots of these scans then performance would benefit from 
the compiler not having to pack the return for an autoreleasing value which 
would have to be released right away due to assignment to _.


IMHO my proposal is more in line with the spirit of the original API: 1) return 
Bool if the scan was successful, 2) optionally return the scanned value.


kind regards
Oliver Drobnik___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Proposal: Improve Import of Scanner APIs into Swift 3

[Alfredo Delli Bovi via swift-corelibs-dev]

Thanks Oliver for bringing this up.

Anyone can share the thread for the draft/experimental API which is in the 
implementation? I cannot find it.

About performance, I think the idea is to return Swift types only and not 
autoreleasing objects anymore.
Still a performance test would be needed to clarify if your proposed solution 
performs better or not.
Also we have to clarify if this suggestion is in line with Swift API guidelines 
and maybe find a trade-off if performance is better.

Cheers,
Alfredo Delli Bovi

> On 30 Nov 2016, at 11:50, Oliver Drobnik via swift-corelibs-dev 
>  wrote:
> 
> Earlier I posted this proposal to the Swift Evolution Mailing list. Then I 
> looked at the NSScanner implementation in core libs and found experimental 
> API using the return value to for returning the scanned results. See my 
> comments on that below:
> 
> 
> —
> 
> Working on a function for Foundation’s Scanner I stumbled on this LLVM crash: 
> https://bugs.swift.org/browse/SR-3295 
> 
> This got me thinking about a workaround and I would like to prose this:
> 
> When importing Foundation into Swift 3, all 
> 
> AutoreleasingUnsafeMutablePointer?
> 
> should instead be exposed as simple:
> 
> inout T?
> 
> e.g.
> 
> open func scanString(_ string: String, into result: 
> AutoreleasingUnsafeMutablePointer?) -> Bool
> 
> would become
> 
> open func scanString(_ string: String, into result: inout String?) -> Bool
> 
> 
> The call would stay exactly the same for normal use cases where you specify a 
> receiving variable:
> 
> var string: String?
> scanString("=", into: &string)
> 
> because inout parameters require a &
> 
> 
> for the use case where you don’t require a receiving parameter, a second 
> method without result parameter would be generated:
> 
> open func scanString(_ string: String) -> Bool
> 
> This is necessary because you cannot specify nil or an immutable value for an 
> inout parameter. 
> 
> 
> A fixit/migration would change calls to
> 
> scanString(“foo", into result: nil)
> 
> into
> 
> scanString(“foo")
> 
> 
> The normal call with receiving variable would stay the same. But the case 
> without return would become more concise.
> 
> What do you think?
> 
> kind regards
> Oliver Drobnik
> 
> —
> 
> The new experimental API does not consider the situation that one might just 
> want to scan a token in a long string and since I know what I am scanning I 
> don’t care about the result. For example in my scanning I would like to 
> processed if I hit a “foo“ … 
> 
> The experimental API would force me to do this:
> 
> if let _ = scanString(“foo“) { }
> 
> My proposal is more elegant:
> 
> if scanString(“foo”) {}
> 
> And if you do lots and lots of these scans then performance would benefit 
> from the compiler not having to pack the return for an autoreleasing value 
> which would have to be released right away due to assignment to _.
> 
> 
> IMHO my proposal is more in line with the spirit of the original API: 1) 
> return Bool if the scan was successful, 2) optionally return the scanned 
> value.
> 
> 
> kind regards
> Oliver Drobnik
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Autoupdating type properties

[Pushkar N Kulkarni via swift-corelibs-dev]

Thanks Tony, for the detailed explanation!  I think I need a bit more clarification though :)>>> Now, nothing in the value type contract says that you cannot have computed properties on a value type. Also, value types are not necessarily “pure”, in the sense that they ignore all external input. What this means for time zone is that its identifier can change depending on user preferences, if its value is “autoupdating". If you set its value to a specific time zone instead, then it does not have the value of “autoupdating" and its computed properties do not behave that way.Please correct me if I am wrong in deriving these from the above:1. `NSTimezone.local` will be a computed type property, which when invoked can return different values (based on user preferences - an external factor) at different points in application's lifetime.2. If NSTimezone.default is explicitly set to a time zone, NSTimezone.local will not reflect that change.3. Existing copies of 'NSTimezone.local' (referring to the example in my question) will also not reflect the change.Pushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-anthony.par...@apple.com wrote: -To: Pushkar N Kulkarni/India/IBM@IBMINFrom: Tony Parker Sent by: anthony.par...@apple.comDate: 11/30/2016 01:39PMCc: swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Autoupdating type propertiesHi Pushkar,On Nov 29, 2016, at 4:12 AM, Pushkar N Kulkarni via swift-corelibs-dev  wrote:Hi there, I am curious about how an autoupdating type property like `NSTimeZone.local` could be implemented, given that it is a value (the type is TimeZone). The requirement essentially is that if the default timezone is changed, the change should reflect in all copies of this value.import Foundationlet local = NSTimeZone.locallet local1 = localprint(local)  //prints the default TimeZoneprint(local1) //prints the default TimeZonelet t = TimeZone(identifier: "America/Chicago")!NSTimeZone.default = tprint(local)    //prints "America/Chicago (autoupdatingCurrent)print(local1)   //prints "America/Chicago (autoupdatingCurrent)What makes it complicated is that TimeZone is a value type. I hope I am not missing something fundamental here!Any ideas or information will be highly appreciated. Thanks!You’re not missing anything fundamental. We considered this case very carefully before proposing these types as value types. I agree that it’s on the borderline, but in the end having it as a value type was too valuable (no pun intended).What we decided is essentially this: the value of the time zone is not its identifier. Instead, abstract it one level. That means that “Autoupdating” can be the actual value. Like an open enumeration.Now, nothing in the value type contract says that you cannot have computed properties on a value type. Also, value types are not necessarily “pure”, in the sense that they ignore all external input. What this means for time zone is that its identifier can change depending on user preferences, if its value is “autoupdating". If you set its value to a specific time zone instead, then it does not have the value of “autoupdating" and its computed properties do not behave that way.I reflected this contract in the == method as well. Autoupdating time zones are equal to other autoupdating time zones. However, the autoupdating time zone is not equal to America/Chicago, even if the current time zone is America/Chicago. let la = TimeZone(identifier: "America/Los_Angeles”) // America/Los_Angeles (current)let tz = TimeZone.autoupdatingCurrent // America/Los_Angeles (autoupdatingCurrent)la == tz // falselet tz2 = TimeZone.autoupdatingCurrent // America/Los_Angeles (autoupdatingCurrent)tz == tz2 // trueIn the case of Calendar, if you mutate it then it is no longer autoupdating — you have changed its value.I’m sure reasonable people could disagree on the direction we chose here, and if we were reinventing the world from scratch I probably would not have added this complication to the API. However, the existing autoupdating concept is used pervasively and I needed a way to fit it into the new system.- TonyPushkar N Kulkarni,IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
___swift-corelibs-dev mailing listswift-corelibs-dev@swift.orghttps://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Autoupdating type properties

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

> On Nov 30, 2016, at 6:39 AM, Pushkar N Kulkarni  wrote:
> 
> Thanks Tony, for the detailed explanation! 
> 
>  I think I need a bit more clarification though :)
> 
> >>> Now, nothing in the value type contract says that you cannot have 
> >>> computed properties on a value type. Also, value types are not 
> >>> necessarily “pure”, in the sense that they ignore all external input. 
> >>> What this means for time zone is that its identifier can change depending 
> >>> on user preferences, if its value is “autoupdating". If you set its value 
> >>> to a specific time zone instead, then it does not have the value of 
> >>> “autoupdating" and its computed properties do not behave that way.
> 
> Please correct me if I am wrong in deriving these from the above:
> 1. `NSTimezone.local` will be a computed type property, which when invoked 
> can return different values (based on user preferences - an external factor) 
> at different points in application's lifetime.
> 2. If NSTimezone.default is explicitly set to a time zone, NSTimezone.local 
> will not reflect that change.
> 3. Existing copies of 'NSTimezone.local' (referring to the example in my 
> question) will also not reflect the change.
> 

Swift clients should really use struct TimeZone instead of class NSTimeZone. I 
updated struct TimeZone’s naming and static functions to be a lot more clear:

/// The time zone currently used by the system.
public static var current : TimeZone


/// The time zone currently used by the system, automatically updating to 
the user's current preference.
///
/// If this time zone is mutated, then it no longer tracks the application 
time zone.
///
/// The autoupdating time zone only compares equal to itself.
public static var autoupdatingCurrent : TimeZone

The ‘current’ struct TimeZone is the ‘system’ NSTimeZone. The 
‘autoupdatingCurrent’ struct TimeZone is the ‘autoupdatingCurrent’ NSTimeZone. 
The ‘default’ NSTimeZone is an awful pattern that nobody should use, because 
it’s likely to be an unexpected value*. I did not include it in struct TimeZone.

The result of calling ‘current’ will change depending on external factors (user 
prefs), but the result from calling it will stay whatever value it was when you 
retrieved it.

The result of calling ‘autoupdatingCurrent’ will always be an autoupdating time 
zone, which will reflect user preferences on its properties when called.

Hope that helps,
- Tony

* details: Anyone can set the default time zone, but once it’s retrieved using 
that class method then your copy no longer updates. So you may think you’re 
setting the default time zone for your app, but in reality if some piece of 
code sets it after some other piece of code gets it, you’re just using two 
different time zones in your app. All of the problems of shared global state.

> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -anthony.par...@apple.com  wrote: 
> -
> To: Pushkar N Kulkarni/India/IBM@IBMIN
> From: Tony Parker 
> Sent by: anthony.par...@apple.com 
> Date: 11/30/2016 01:39PM
> Cc: swift-corelibs-dev  >
> Subject: Re: [swift-corelibs-dev] Autoupdating type properties
> 
> Hi Pushkar,
> 
>> On Nov 29, 2016, at 4:12 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi there, 
>> 
>> I am curious about how an autoupdating type property like `NSTimeZone.local` 
>> could be implemented, given that it is a value (the type is TimeZone). The 
>> requirement essentially is that if the default timezone is changed, the 
>> change should reflect in all copies of this value.
>> 
>> import Foundation
>> 
>> 
>> 
>> let local = NSTimeZone.local
>> 
>> let local1 = local
>> 
>> print(local)  //prints the default TimeZone
>> 
>> print(local1) //prints the default TimeZone
>> 
>> 
>> 
>> let t = TimeZone(identifier: "America/Chicago")!
>> 
>> NSTimeZone.default = t
>> 
>> 
>> 
>> print(local)//prints "America/Chicago (autoupdatingCurrent)
>> 
>> print(local1)   //prints "America/Chicago (autoupdatingCurrent)
>> 
>> 
>> 
>> What makes it complicated is that TimeZone is a value type. I hope I am not 
>> missing something fundamental here!
>> 
>> Any ideas or information will be highly appreciated. Thanks!
> 
> You’re not missing anything fundamental. We considered this case very 
> carefully before proposing these types as value types. I agree that it’s on 
> the borderline, but in the end having it as a value type was too valuable (no 
> pun intended).
> 
> What we decided is essentially this: the value of the time zone is not its 
> identifier. Instead, abstract it one level. That means that “Autoupdating” 
> can be the actual value. Like an open enumeration.
> 
> Now, nothing in the value type contract says that you cannot have computed 

[swift-corelibs-dev] Fatal error Foundation/NSCalendar.swift, Ubuntu 16.04, Swift 3.0.1

[Malcolm Barclay via swift-corelibs-dev]

Hi,

Is this a bug in the NSCalendar.swift? On Ubuntu 16.04 with Swift 3.0.1 
installed this crashes.

import Foundation
let fromDate = Date()
let toDate = Date(timeIntervalSinceNow: 20)
let components = Calendar.current.dateComponents([.second], from: fromDate, to: 
toDate)

Result:

fatal error: file Foundation/NSCalendar.swift, line 615
fromDate: Foundation.Date = {
  _time = 

}
toDate: Foundation.Date = {
  _time = 

}
components: Foundation.DateComponents = {
  _handle = 

}
Execution interrupted. Enter code to recover and continue.
Enter LLDB commands to investigate (type :help for assistance.)

Variations of other components also fails, e.g .hour, .minute etc.

Best regards,
Malcolm
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Fatal error Foundation/NSCalendar.swift, Ubuntu 16.04, Swift 3.0.1

[Tony Parker via swift-corelibs-dev]

Hi Malcolm,

Looks like it. If you go ahead and file a JIRA at bugs.swift.org 
, hopefully someone can take a look.

Thanks,
- Tony

> On Nov 30, 2016, at 6:22 AM, Malcolm Barclay via swift-corelibs-dev 
>  wrote:
> 
> Hi,
> 
> Is this a bug in the NSCalendar.swift? On Ubuntu 16.04 with Swift 3.0.1 
> installed this crashes.
> 
> import Foundation
> let fromDate = Date()
> let toDate = Date(timeIntervalSinceNow: 20)
> let components = Calendar.current.dateComponents([.second], from: fromDate, 
> to: toDate)
> 
> Result:
> 
> fatal error: file Foundation/NSCalendar.swift, line 615
> fromDate: Foundation.Date = {
>  _time = 
> 
> }
> toDate: Foundation.Date = {
>  _time = 
> 
> }
> components: Foundation.DateComponents = {
>  _handle = 
> 
> }
> Execution interrupted. Enter code to recover and continue.
> Enter LLDB commands to investigate (type :help for assistance.)
> 
> Variations of other components also fails, e.g .hour, .minute etc.
> 
> Best regards,
> Malcolm
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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