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

If you look at the implementation I provided, it allows for percentages higher than 100% (and has an easy way to clip them or map them to an arbitrary range). > On Jan 16, 2018, at 11:39 AM, Dave DeLong via swift-evolution > wrote: > > > >> On Jan 16, 2018, at 9:56 AM, Jon Gilbert via swift

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

Mainly semantics. We could technically use Int instead of having a Bool type (just using 1 and 0). We don’t do that since Int and Bool have intrinsically different meanings in code. What I am saying is that parameters that take the range 0 to 1 typically have a fundamentally different meani

[swift-evolution] Reminder: Discourse transition starts tomorrow

Hi All- Just a reminder that we’ll be suspending the mailing lists tomorrow in the early evening in order to start the transition to Discourse… Cheers! nicole > On Jan 10, 2018, at 12:21 PM, Nicole Jacque wrote: > > Hi All- > > First of all, a big thank you to everyone who has provided feedb

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

On Tue, Jan 16, 2018 at 6:20 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > On Tue, Jan 16, 2018 at 6:31 PM, Xiaodi Wu wrote: > >> On Tue, Jan 16, 2018 at 4:30 PM, Nevin Brackett-Rozinsky < >> nevin.brackettrozin...@gmail.com> wrote: >> >>> The thing that is “broken” her

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

On Tue, Jan 16, 2018 at 6:31 PM, Xiaodi Wu wrote: > On Tue, Jan 16, 2018 at 4:30 PM, Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > >> The thing that is “broken” here is generic programming. If I constrain >> something to FloatingPoint, I cannot use a float literal in calc

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

On Tue, Jan 16, 2018 at 5:39 PM, Rick Mann wrote: > > > > On Jan 16, 2018, at 15:32 , Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Jan 16, 2018, at 14:30 , Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> That only works

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

> On Jan 16, 2018, at 15:32 , Xiaodi Wu via swift-evolution > wrote: > > On Jan 16, 2018, at 14:30 , Nevin Brackett-Rozinsky via swift-evolution > wrote: >> >> That only works for numbers which don’t overflow the integer literals >> though. If we want a really large or small value then we

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

On Tue, Jan 16, 2018 at 4:30 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > The thing that is “broken” here is generic programming. If I constrain > something to FloatingPoint, I cannot use a float literal in calculations > with it: > > func centimeters (inches: T) -> T {

Re: [swift-evolution] String update

> On Jan 16, 2018, at 2:18 PM, Michael Ilseman via swift-evolution > wrote: > > (Replying to both Eneko and George at once) > > I wonder if it is worth considering (for lack of a better word) *verbose* > regular expression for Swift. > > > > It is certainly worth thought; ev

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

The thing that is “broken” here is generic programming. If I constrain something to FloatingPoint, I cannot use a float literal in calculations with it: func centimeters (inches: T) -> T { return 2.54 * inches// Error } Of course, “T: FloatingPoint” is an overconstraint in this example,

Re: [swift-evolution] String update

Significant leading zeros is a good point. Another would be non-default-radix. > On Jan 16, 2018, at 12:22 PM, C. Keith Ray via swift-evolution > wrote: > > people may want digits as characters in order to see zeros. parsing phone > numbers and social security numbers need zeros. > > C. Keith

Re: [swift-evolution] String update

(Replying to both Eneko and George at once) I wonder if it is worth considering (for lack of a better word) *verbose* regular expression for Swift. >>> It is certainly worth thought; even if we don’t go down that path there’s lessons to pick up along the way. I believe “verbal expr

Re: [swift-evolution] [swift-users] Cannot pass immutable value as inout argument

I don’t know how C API is imported, btus INOUT parameter must be mutable, this is a language artifact. Am 16. Januar 2018 um 22:10:13, Rick Mann via swift-users (swift-us...@swift.org) schrieb: Is it not possible for Swift to treat C API const pointers as something that can take let arguments

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

Is interesting that the topic is going in this direction. The question of "how an API “gets finalized” it's been something that has been a little worrying for a while. The fact that a change in Swift goes from Proposal to Oficial, part of the lang *for ever*, has bitten us in the past already. My u

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

> On Jan 13, 2018, at 1:40 PM, Erica Sadun wrote: > > > >> 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"

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

On Jan 15, 2018, at 11:01 PM, Xiaodi Wu via swift-evolution wrote: > - Can we change the semantics? Maybe, but I doubt ExpressibleByFloatLiteral > can be outright replaced. You're not the first to wonder about how to design > an alternative protocol. Dig through the archives and you'll find som

Re: [swift-evolution] String update

people may want digits as characters in order to see zeros. parsing phone numbers and social security numbers need zeros. C. Keith Ray https://leanpub.com/wepntk <- buy my book? http://agilesolutionspace.blogspot.com/ twitter: @ckeithray http://www.thirdfoundationsw.com/keith_ray_resume_2014_long

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

> On Jan 16, 2018, at 9:56 AM, Jon Gilbert via swift-evolution > wrote: > > No to this pitch, because a percentage can be higher than 100%. ☝️ One need only look in Activity Monitor to see this in action. > Use NumberFormatter to display a number as a percentage. > https://developer.apple.c

Re: [swift-evolution] String update

Thank you for the reply. The part I didn’t understand is if if giving names to the captured groups would be mandatory. Hopefully not. Assuming we the user does not need names, the groups could be captures on an unlabeled tuple. Digits could always be inferred to be numeric (Int) and they should

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

> On Jan 14, 2018, at 09:36, Vladimir.S wrote: > > > > On 12.01.2018 21:38, Jordan Rose wrote: >>> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution mailto:swift-e

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

> On Jan 12, 2018, at 22:49, Chris Lattner wrote: > > >> On Jan 12, 2018, at 3:08 PM, Jordan Rose wrote: >> >> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's >> point very specifically: if the compiler emits an error, we should go with >> `case #unknown` instead

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

> On Jan 13, 2018, at 18:33, Chris Lattner wrote: > > 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 al

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

Is this equivalent to `default: break`? `default: fatalError()`? I think it's better to write such things explicitly. Jordan > On Jan 14, 2018, at 21:51, Tim Wang wrote: > > I would like to add a syntax sugar .casesBelow for enum value to be used in > switch sentence to avoid default case. >

Re: [swift-evolution] String update

@Eneko While it sure seems possible to specify the type, I think this would go against the salient point "If something’s worth capturing, it’s worth giving it a name.” Putting the name further away seems like a step backward. I could imagine a slightly more succinct syntax where things like .n

Re: [swift-evolution] String update

Could it be possible to specify the regex type ahead avoiding having to specify the type of each captured group? let usPhoneNumber: Regex = / (\d{3}?) - (\d{3}) - (\d{4}) / “Verbose” alternative: let usPhoneNumber: Regex = / .optional(.numberFromDigits(.exactly(3)) + "-“) + .number

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

No to this pitch, because a percentage can be higher than 100%. Use NumberFormatter to display a number as a percentage. https://developer.apple.com/documentation/foundation/numberformatter Or you could make an NSNumber subclass if you want to enforce an arbitrary rule upon numbers. Jonathan

Re: [swift-evolution] String update

Thanks, Michael. This is very interesting! I wonder if it is worth considering (for lack of a better word) *verbose* regular expression for Swift. For instance, your example: ``` let usPhoneNumber = / (let area: Int? <- \d{3}?) - (let routing: Int <- \d{3}) - (let local: Int <- \d{4}) / ``

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

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

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

> On 15. Jan 2018, at 23:55, Taylor Swift wrote: > > > > On Jan 15, 2018, at 3:30 PM, Karl Wagner > wrote: > >> >> >>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> This could work, but you’re al

[swift-evolution] Pure functions

Should we add support for recognition of pure functions? These functions don’t refer to any global state; their return values / outgoing in-out parameter states depend solely on the incoming argument values. I know at least the D programming language acknowledges them. - Should they be marked