Re: [swift-corelibs-dev] Locale formatting (UAMeasureFormat)

[Philippe Hausler via swift-corelibs-dev]

Length, Energy and Mass formatters should definitely use the ICU backing. It 
might be a good idea to funnel them all into one unit formatter access point. I 
personally find it is sometimes easier to interface to C APIs in C and expose 
them back up as simple funnel methods but it depends on which APIs you are 
interfacing with so ymmv. The formatters are locale independent in that they 
should probably just have a simple callout to uameasfmt_format when creating 
strings from values given a certain unit type.


> On Jan 5, 2016, at 1:23 PM, Johan Jensen via swift-corelibs-dev 
>  wrote:
> 
> I was having a quick look at implementing some of the not-yet-implemented 
> formatters but quickly realized that some of them are highly locale dependent.
> After a quick look I found uameasureformat.h 
> 
>  and uameasfmt_format() which looks quite interesting.
> Is it possible to use these functions?
> If so, should a Swift wrapper be made?
> If not, how is locale dependent formatters expected to be implemented?
> 
> — Johan
>  ___
> 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

[swift-corelibs-dev] Locale formatting (UAMeasureFormat)

[Johan Jensen via swift-corelibs-dev]

I was having a quick look at implementing some of the not-yet-implemented
formatters but quickly realized that some of them are highly locale
dependent.
After a quick look I found uameasureformat.h

and uameasfmt_format() which looks quite interesting.
Is it possible to use these functions?
If so, should a Swift wrapper be made?
If not, how is locale dependent formatters expected to be implemented?

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

Re: [swift-corelibs-dev] #if __CORELIBS_FOUNDATION__

[Tony Parker via swift-corelibs-dev]

Hi Drew,

> On Jan 5, 2016, at 12:08 AM, Drew Crawford  wrote:
> 
> 
>> On Jan 4, 2016, at 3:09 PM, Tony Parker > > wrote:
>> 
>> In this particular case, how would you use the #if? Any should be source 
>> compatible with AnyObject, since Any is a superset of AnyObject, right?
> 
> Well I don't know what you mean by "compatible" but the thing about strongly 
> typed languages is we can't do
> 
> let a: Any
> 
> foo(a: AnyObject) { /* */ }
> 
> foo(a)
> 
> because that is "type error".  We can of course cast, but if in Darwin a.self 
> is already AnyObject, casting again to AnyObject produces a warning, and I 
> try to not have any warnings in my code.
> 
> This is kind of a side quest–there are a lot of ways to work around these 
> problems–but the obviously straightforward one was to use #if to 
> conditionally cast, and that wasn't available.
> 
> More broadly I find myself using the #if that I've created very often–my 
> workflow seems to be to create an extension on an NSClass in-file that adds 
> missing functionality and then PR it to corelibs-foundation afterwards–and 
> conditional compilation really helps with that workflow.

My main objection is that I don’t want us to require clients to #if at all, in 
the long term. Putting it in now means that it will be easier to say “just #if” 
instead of fixing the underlying source incompatibility problem.

I think that if we get to a time nearer to the finish line of Swift 3 and we 
still have many source incompatible changes between the Core Libs Foundation 
and a corresponding Darwin Foundation then we should introduce something like 
the #if.

- Tony

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

Re: [swift-corelibs-dev] NSRegularExpression implementation

[Philippe Hausler via swift-corelibs-dev]

NSRegularExpression is backed by ICU’s uregex; there is no regex support in CF 
however since ICU is a pretty involved C API it would not be un-reasonable to 
create an accessor API to make certain behaviors easier to deal with in swift.

> On Jan 4, 2016, at 8:58 PM, Lukas Stabe via swift-corelibs-dev 
>  wrote:
> 
> I have been thinking about trying to work on NSRegularExpression in 
> corelibs-foundation, although I am not yet sure I’ll have time for it.
> 
> If I were to attempt it, am I correct in assuming that it should be based on 
> icus (u)regex.h? I have not found any Regex support in CoreFoundation.
> 
> — Lukas
> ___
> 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] #if __CORELIBS_FOUNDATION__

[Drew Crawford via swift-corelibs-dev]

> On Jan 4, 2016, at 3:09 PM, Tony Parker  wrote:
> 
> In this particular case, how would you use the #if? Any should be source 
> compatible with AnyObject, since Any is a superset of AnyObject, right?

Well I don't know what you mean by "compatible" but the thing about strongly 
typed languages is we can't do

let a: Any

foo(a: AnyObject) { /* */ }

foo(a)

because that is "type error".  We can of course cast, but if in Darwin a.self 
is already AnyObject, casting again to AnyObject produces a warning, and I try 
to not have any warnings in my code.

This is kind of a side quest–there are a lot of ways to work around these 
problems–but the obviously straightforward one was to use #if to conditionally 
cast, and that wasn't available.

More broadly I find myself using the #if that I've created very often–my 
workflow seems to be to create an extension on an NSClass in-file that adds 
missing functionality and then PR it to corelibs-foundation afterwards–and 
conditional compilation really helps with that workflow.___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev