Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Alternatively, from a different perspective, rather than adding a new ABI-unstable library that gets bundled with apps, another way to look at it is that we already *have* an ABI-unstable library that gets bundled with apps. So we can instead think about introducing a new library with a stable

Re: [swift-evolution] [Pitch] Angle Type

> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution > wrote: > > This could work, but you’re also giving up all the nice Numeric and > FloatingPoint conformances when you use this,, all of a sudden adding two > angles together isn’t let γ = α + β, it’s γ =

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Pardon my lack of knowledge in this area, but is there not also a 3rd option available? (C) Split libswiftCore.dylib into two dylibs, both at the OS level. The *Deprecated.dylib would only be included when the application binary was compiled using a special -using-deprecated flag that

Re: [swift-evolution] [Pitch] Angle Type

> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution > wrote: > >> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution >> > wrote: >> >> This could work, but you’re also giving up all the

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

This. I asked that already and they not understand me very well. I see no reason for each app to have its own version of "deprecated lib". Also we can keep the libswiftCore_4.1.dylib, libswiftCore_5.0.dylib, libswiftCore_5.1.dylib etc on the SO too. The default target must be libswiftCore.dylib,

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

For some OS vendors it may be feasible to have multiple Swift runtimes installed on the system to be used by different apps. That, however, is not an option if you actually want the libraries in the OS — in the case of macOS and iOS the OS frameworks — to actually use Swift themselves. At the

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Mon, Jan 15, 2018 at 11:27 PM, Xiaodi Wu wrote: > On Mon, Jan 15, 2018 at 20:37 Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > >> >> That protocol is spelled ExpressibleByFloatLiteral, which reflects the >> meaning that we want and should have. The

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Hi Nevin, I think this is an interesting perspective. For me it begets the question of how an API “gets finalized”. Currently anything that goes through the Swift Evolution proposal process that gets ratified is considered an official change to the language and Standard Library. That feels

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Tue, Jan 16, 2018 at 00:32 Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > On Mon, Jan 15, 2018 at 11:27 PM, Xiaodi Wu wrote: > >> On Mon, Jan 15, 2018 at 20:37 Nevin Brackett-Rozinsky < >> nevin.brackettrozin...@gmail.com> wrote: >> >>> >>> That

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Mon, Jan 15, 2018 at 20:37 Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > On Mon, Jan 15, 2018 at 8:51 PM, Xiaodi Wu wrote: > >> On Mon, Jan 15, 2018 at 19:20 Nevin Brackett-Rozinsky < >> nevin.brackettrozin...@gmail.com> wrote: >> >>> All I’m saying

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Mon, Jan 15, 2018 at 4:24 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > Currently, the FloatingPoint protocol does not conform to > ExpressibleByFloatLiteral, whereas BinaryFloatingPoint does. > > The only explanation I can find for this is a brief

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

All I’m saying is the current situation seems semantically wrong. As in, how can a type claim to be a floating point number, if it *literally* cannot be represented by a floating point number? You suggest treating a float literal as a string, but another alternative is to teach the compiler to

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Mon, Jan 15, 2018 at 8:51 PM, Xiaodi Wu wrote: > On Mon, Jan 15, 2018 at 19:20 Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > >> All I’m saying is the current situation seems semantically wrong. As in, >> how can a type claim to be a floating point

Re: [swift-evolution] [Pitch] Angle Type

> On Jan 15, 2018, at 3:30 PM, Karl Wagner wrote: > > > >> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution >> wrote: >> >> This could work, but you’re also giving up all the nice Numeric and >> FloatingPoint conformances when you

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Mon, Jan 15, 2018 at 19:20 Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > All I’m saying is the current situation seems semantically wrong. As in, > how can a type claim to be a floating point number, if it *literally* > cannot be represented by a floating point number? >

[swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

Currently, the FloatingPoint protocol does not conform to ExpressibleByFloatLiteral, whereas BinaryFloatingPoint does. The only explanation I can find for this is a brief comment from Steve Canon during the

Re: [swift-evolution] [Pitch] Angle Type

> On Jan 15, 2018, at 3:40 PM, Stephen Canon wrote: > > > >>> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution >>> wrote: >>> >>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution >>> wrote: >>>