Re: [swift-evolution] [pitch] adding toggle to Bool

I am yet another one that tries to never use ! It feels like bad heritage from C, and it probably should be removed from Swift in the same way for(;;) and ++/-- where removed. ! does not provide any unique functionality, as it is redundant to “== false”. Other than syntax sugar, it does not

Re: [swift-evolution] [Proposal] Random Unification

On Sat, Jan 13, 2018 at 10:29 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > I think a full random implementation should be decoupled from Swift's > standard library and generic random is overkill. > > In-language, I think pre-seeded random uniform (0 ..< 1, >

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

As Erica mentioned about Angle, this seems to be a perfect fit for an appropriately focused third-party library, but I'm not sure I appreciate why this should be part of the standard library. In large part, you seem to have reinvented a decimal type, which is already available in the form of

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

An Angle type already exists in Foundation; see Measurement. You could add some convenience methods in an extension pretty easily. import Foundation typealias Angle = Measurement extension Measurement where UnitType == UnitAngle { var sine: Double { let radians = self.converted(to:

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

I would like to see a full Geometry implementation but I don't think it should be part of the standard library. I've kicked around some ideas here: * https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b *

Re: [swift-evolution] [Proposal] Random Unification

I think a full random implementation should be decoupled from Swift's standard library and generic random is overkill. In-language, I think pre-seeded random uniform (0 ..< 1, `Double.uniformRandom()`), random int (0 ..< max, `Int.uniform(max)`), and random index for indexed collection

Re: [swift-evolution] [Proposal] Random Unification

For a range of 0..<(2<

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

Here is the code I use for percentage myself. (I incorrectly said I use a UInt64… I use a UInt32): ///Represents a percentage with the precision of millionths of 1 (i.e. 4 decimal places: XX.%). The value is always positive (or zero), but may be greater than 100% struct Percentage {

[swift-evolution] [Pitch] Angle Type

Hi Evolution, I would really like to see Swift gain an Angle type in the standard library. Every time I have to deal with an angle in an api, I have to go figure out the conventions for that call. Is it in degrees? Is it in radians? What if it is in radians, but I want to think about it in

Re: [swift-evolution] [Proposal] Random Unification

Could someone measure how bad the "random(32 bits) mod m" problem actually is? It's prominent when the number of bits is close to m, eg 4 bits and m == 3. Is it bad when bits == 32 and m is less than 2^16? Or bits == 64 and m is less than 2^32? C. Keith Ray https://leanpub.com/wepntk <- buy my

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I don’t understand why #unknown wouldn’t work in catch clauses. In the absence of typed throws you can’t match on an enums case without the enums base: you can’t use .foo, you have to use MyEnum.foo. Similarly, catch wouldn’t allow .#unknown, it would require MyEnum.#unknown. This is

[swift-evolution] [Pitch] Percentage Type

Hi Evolution, I was wondering if we would consider adding a percentage type to Swift. This would be a type with a value between 0 & 1. I know we can and do use doubles or floats for this now, but there really is a semantic difference between most parameters that take a value between 0 & 1 and

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 12, 2018, at 8:22 PM, Nate Cook wrote: > > On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution > > wrote: > >> I think we have different definitions of consistency. I am fine with the >>

Re: [swift-evolution] [Proposal] Random Unification

Basically, my point is that I want to be able to operate generically. > On Jan 13, 2018, at 5:20 AM, Letanyan Arumugam wrote: > > >> On 13 Jan 2018, at 02:24, Jonathan Hull > > wrote: >> >> I think we have different definitions of

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 13, 2018, at 5:20 AM, Letanyan Arumugam wrote: > > >> On 13 Jan 2018, at 02:24, Jonathan Hull > > wrote: >> >> I think we have different definitions of consistency. I am fine with the >> ergonomics of (0…100).random()

Re: [swift-evolution] [pitch] adding toggle to Bool

> On Jan 11, 2018, at 22:15, Chris Eidhof via swift-evolution > wrote: > > Hey SE! > > When we have a bunch of nested structs: > > struct Sample { > var bar: Bar > } > > struct Bar { > var show: Bool > } > > var foo =

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

Perhaps bring the three special case literals into this as well? (File, image, color) -- E > On Jan 9, 2018, at 4:53 PM, Ben Cohen via swift-evolution > wrote: > > Big +1 to this. Getting these types out of the standard library and into a > more suitable

Re: [swift-evolution] [pitch] adding toggle to Bool

On Jan 13, 2018, at 12:06 PM, Karl Wagner via swift-evolution wrote: > >> On 12. Jan 2018, at 20:54, Alejandro Martinez via swift-evolution >> > wrote: >> >> I wouldn't go as far as to ask to fade out !

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

> On Jan 9, 2018, at 10:22 PM, Brent Royal-Gordon via swift-evolution > wrote: > If we can't do this, I think we should call it something like `PairArray` or > `KeyValueArray` Or "KeyValueList", which avoids both "Dictionary" and "Array" words. -- E

Re: [swift-evolution] No disjunctions in type constraints: why?

The “Swifty” way of doing such a thing is to have the types you care about conform to a protocol that clearly defines the API you’re trying to expose. For example: protocol Fooable { func doFoo() } extension Int: Fooable { func doFoo() { print("I’m an Int")

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

Why is that a problem? Despite referring to it as the “unstable” half, if we just put deprecated stuff in it, it would still be stable and should work for that. You are right that things would be more complicated if it is used as a “staging ground” for features that eventually make it into

Re: [swift-evolution] [pitch] adding toggle to Bool

The trues is that `isTrue` doesn’t really make sense because boolean instances are named in a way where `isTrue` is rendered redundant. Am 13. Januar 2018 um 20:09:41, C. Keith Ray via swift-evolution (swift-evolution@swift.org) schrieb: If you would like something better than "== false" I

Re: [swift-evolution] [pitch] adding toggle to Bool

(I know isTrue is redundant. I only considered it for symmetry.) > On Jan 13, 2018, at 11:09 AM, C. Keith Ray wrote: > > If you would like something better than "== false" I suggest adding computed > properties 'isTrue' and 'isFalse' to Boolean. > > >> On Jan 13, 2018, at

Re: [swift-evolution] [pitch] adding toggle to Bool

If you would like something better than "== false" I suggest adding computed properties 'isTrue' and 'isFalse' to Boolean. > On Jan 13, 2018, at 11:06 AM, Karl Wagner via swift-evolution > wrote: > > > >> On 12. Jan 2018, at 20:54, Alejandro Martinez via

Re: [swift-evolution] [pitch] adding toggle to Bool

Well I only used the previously mentioned names, in my codebase I use `isFalse` for that situation which is better then `== false` in my opinion. Am 13. Januar 2018 um 20:06:21, Karl Wagner (razie...@gmail.com) schrieb: > On 12. Jan 2018, at 20:54, Alejandro Martinez via swift-evolution >

Re: [swift-evolution] [pitch] adding toggle to Bool

> On 12. Jan 2018, at 20:54, Alejandro Martinez via swift-evolution > wrote: > > I wouldn't go as far as to ask to fade out ! but in all my code I end > up doing == false just for readability. That ! knows who to hide > himself too well :P > Yeah so do I. ! is a

Re: [swift-evolution] [pitch] adding toggle to Bool

Thanks for all the feedback everyone, I just submitted a short proposal as a PR: https://github.com/apple/swift-evolution/pull/782 On Fri, Jan 12, 2018 at 11:34 PM, Anders Kierulf via swift-evolution < swift-evolution@swift.org> wrote: > I also avoid using ! for negation when possible, and

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On 13. Jan 2018, at 03:22, Connor Wakamo via swift-evolution > wrote: > > > >> On Jan 11, 2018, at 11:51 PM, Chris Lattner > > wrote: >> >> On Jan 11, 2018, at 11:22 AM, Connor Wakamo >

Re: [swift-evolution] [Proposal] Random Unification

> On 13 Jan 2018, at 02:24, Jonathan Hull wrote: > > I think we have different definitions of consistency. I am fine with the > ergonomics of (0…100).random() as a convenience, but it really worries me > here that everything is special cased. Special cased things are fine

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

One major drawback of splitting Coe library, is that despite having a stable ABI, you break the possibility to include binary frameworks inside an application unless they both link on the same version of libswiftCoreDeprecated.dylib (assuming libswiftCoreDeprecated.dylib has not a stable ABI,

[swift-evolution] No disjunctions in type constraints: why?

>From >. Maybe I’m not up on my Type Theory, but why should type constraint disjunctions be banned? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com

Re: [swift-evolution] [Proposal] Random Unification

On Fri, Jan 12, 2018 at 10:23 PM, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > I think we have different definitions of consistency. I am fine with the > ergonomics of

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

On Wed, Jan 10, 2018 at 5:06 AM, Brent Royal-Gordon wrote: > On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I continue to have concerns about this proposal, and I'm gravely and very > bitterly disappointed that the