<mailto:swift-infrastruct...@swift.org>,
code-own...@swift.org, and cond...@swift.org will continue to work.
See you in the Swift Forums!
nicole___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo
If there are
> any unexpected delays, I’ll communicate that via the lists as well. In the
> meantime, you can still communicate with me and the rest of the Swift
> infrastructure team if necessary at infrastruct...@swift.org.
>
> Cheers!
> nicole
_____
...@swift.org.
Cheers!
nicole
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Saagar Jha
> On Jan 17, 2018, at 16:56, Xiaodi Wu via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> On Wed, Jan 17, 2018 at 2:04 AM, David Sweeris <daveswee...@mac.com
> <mailto:daveswee...@mac.com>> wrote:
>
>
> Sent from my iPhone
>
On Wed, Jan 17, 2018 at 2:04 AM, David Sweeris <daveswee...@mac.com> wrote:
>
>
> Sent from my iPhone
>
> > On Jan 16, 2018, at 23:45, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Mainly semantics.
> >
> &
On Wed, Jan 17, 2018 at 4:56 PM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:
> I’m with Nevin on this one. Perhaps the easiest thing to do is to add
> something to the FloatLiteral type that lets you get it as a string if
> desired.
>
> Didn’t
s.
>
> Connor
>
>>>> Is the problem the “one” case? If that is the problem, then it might be
>>>> better to take a completely different approach where you embrace the fact
>>>> that you have structured data producing 2D results that need to be
>>>> displayed. Each result could either return an atomic result or a result
>>>> that wraps some other recursive 2D presentation.
>>>
>>> No, the issue is that the playground logger would see that `Foo.two`
>>> conforms to `CustomPlaygroundConvertible`, and would therefore call
>>> `playgroundDescription` another time, which would return another `Foo.two`,
>>> and this would continue endlessly. I plan to guard against that in
>>> PlaygroundLogger with a limit on chaining, but this protocol should not
>>> require a failsafe as a feature.
>>
>> Right, it seems like the best way to solve this is to provide explicit
>> access to the default presentation.
>>
>> -Chris
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
t it is a statement at the moment. But I don't
> think it needs to be modeled as a statement attribute/modifier. A flag on
> CaseStmt is fine.
DeclModifiers are a syntax/parser thing, not a representational concept in the
AST. Storing it as a bit would be fine, I’d also prefer that.
-Chris
nk we have a statement modifier yet. That said, we’ve always
>> planned to have them when the need arose.
>
> ‘case’ isn’t a decl in switches either. Nor is it a statement, the way things
> are modeled today.
Bleah, sorry, I forgot that it is a statement at the moment. But I don't think
it needs to be modeled as a statement attribute/modifier. A flag on CaseStmt is
fine.
Jordan
> But this is all implementation detail; it’s not interesting to discuss that.
>
> Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
String)>
>
> On 16 Jan 2018, at 23:20, Michael Ilseman via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> Significant leading zeros is a good point. Another would be
>> non-default-radix.
>>
>>
> On Jan 13, 2018, at 2:18 PM, Erica Sadun <er...@ericasadun.com> wrote:
>
> On Jan 11, 2018, at 1:40 PM, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>> On Jan 11, 2
> On Jan 13, 2018, at 8:20 AM, Karl Wagner <razie...@gmail.com> wrote:
>
>
>
>> On 13. Jan 2018, at 03:22, Connor Wakamo via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>
gt;>> displayed. Each result could either return an atomic result or a result
>>> that wraps some other recursive 2D presentation.
>>
>> No, the issue is that the playground logger would see that `Foo.two`
>> conforms to `CustomPlaygroundConvertible`, and would therefore call
>> `playgroundDescription` another time, which would return another `Foo.two`,
>> and this would continue endlessly. I plan to guard against that in
>> PlaygroundLogger with a limit on chaining, but this protocol should not
>> require a failsafe as a feature.
>
> Right, it seems like the best way to solve this is to provide explicit access
> to the default presentation.
>
> -Chris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
. I
view this as a bug.
Thanks,
Jon
> On Jan 16, 2018, at 4:20 PM, Nevin Brackett-Rozinsky via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> On Tue, Jan 16, 2018 at 6:31 PM, Xiaodi Wu <xiaodi...@gmail.com
> <mailto:xiaodi...@gmail.com>> wrote:
t a decl, and I
> don’t think we have a statement modifier yet. That said, we’ve always
> planned to have them when the need arose.
‘case’ isn’t a decl in switches either. Nor is it a statement, the way things
are modeled today. But this is all implementation detail; it’s not interesting
to discuss that.
Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
my proposal fits
directly into that. The only extension is that ‘default’ isn’t a decl, and I
don’t think we have a statement modifier yet. That said, we’ve always planned
to have them when the need arose.
-Chris_______
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
ing] <- \w)* \s
(let lastName: String <- \w+)
/
print(type(of: name)) // => Regex<(firstName: String, initials: [Character],
lastName: String)>
On 16 Jan 2018, at 23:20, Michael Ilseman via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
> On Jan 17, 2018, at 11:53 AM, Saagar Jha via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Interestingly, it seems like Swift allows for contravariance for subclassing,
> in that this is valid code:
>
> protocol A {}
> protocol B: A {}
>
> cl
;func test(x: TestInput)
>> }
>>
>> Curiously, the following does not work, although it seems like it should:
>>
>> protocol A {}
>> protocol B: A {}
>>
>> protocol C {
>>associatedtype TestOutput: A
>>
>>
}
>
> class M: C {
>func test() -> B {
> fatalError("just a stub")
>}
> }
>
> It gives the error “inferred type 'B' (by matching requirement 'test()') is
> invalid: does not conform to ‘A’” even though B does conform to A.
fatalError("just a stub")
}
}
It gives the error “inferred type 'B' (by matching requirement 'test()') is
invalid: does not conform to ‘A’” even though B does conform to A. Huh.
Cheers, P
> On Jan 17, 2018, at 2:43 AM, Saagar Jha via swift-evolution
> <swift-ev
.
~Robert Widmann
2018/01/13 4:45、Daryle Walker via swift-evolution
<swift-evolution@swift.org>のメール:
> From
> <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md#miscellaneous>.
>
> Maybe I’m not up on my Type Theory, but why should type constraint
If we have:
class N: A {}
you can pass an N into C’s test(x:), since N is an A, but not M’s test(x:),
since N is not a B. Thus, it’s not a valid conformance.
Saagar Jha
> On Jan 17, 2018, at 00:04, Roshan via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Hi,
test(x: B) {}
}
Is there a reason why the compiler doesn't infer that ((B) -> ())
matches ((A) -> ()) because of inheritance?
--
Warm regards
Roshan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/li
Sent from my iPhone
> On Jan 16, 2018, at 23:45, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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
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
> <swift-evolution@swift.org> wrote:
>
>
>
>
l type, which is already available in the form of
> Foundation.Decimal on all supported platforms.
>
> On Sat, Jan 13, 2018 at 9:07 PM, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Here is the code I u
outage time between
> the mailing lists going down and the forums being ready.
>
> If you need to contact the Swift infrastructure team during the outage period
> the infrastruct...@swift.org email will continue to work.
>
> Thanks!
> nicole
______
could write:
>>
>> func moles(particles: T)
>> -> T {
>> let N_A = T("6.02214085774e+23")!
>> return particles / N_A
>> }
>>
>
> …or I could write “T: FloatingPoint & ExpressibleByFloatLiteral”. I could
> even make a typealias for that. But I shouldn’t have to.
>
Sure, you could do that too. Your solution here is actually probably the
best, in that if a user wishes to conform a decimal type
to ExpressibleByFloatLiteral, your extensions would also work for that
type. I've already explained why the semantics of ExpressibleByFloatLiteral
are such that not every FloatingPoint type could conform.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
}
>>
>> It would be much nicer to write “let avogadroNumber: T = 6.022140857e23”.
>>
>
> You could write:
>
> func moles(particles: T)
> -> T {
> let N_A = T("6.02214085774e+23")!
> return particles / N_A
> }
>
…or I could write “T: FloatingPoint & ExpressibleByFloatLiteral”. I could
even make a typealias for that. But I shouldn’t have to.
Nevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
> 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 for numbers wh
On Tue, Jan 16, 2018 at 3:39 PM, Chris Lattner <clatt...@nondot.org> wrote:
>
>> On Jan 15, 2018, at 11:01 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > - Can we change the semantics? Maybe, but I doubt
>> ExpressibleByFloatLite
> On Jan 16, 2018, at 2:18 PM, Michael Ilseman via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> (Replying to both Eneko and George at once)
>
>>>>> I wonder if it is worth considering (for lack of a better word) *verbose*
Tue, Jan 16, 2018 at 3:39 PM, Chris Lattner <clatt...@nondot.org> wrote:
> On Jan 15, 2018, at 11:01 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> > - Can we change the semantics? Maybe, but I doubt
> ExpressibleByFloatLiteral can be out
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
> <swift-evolution@swift.org> wrote:
>
> people may want digits as characters in order to see zeros. parsing phone
> number
along the way. I believe “verbal expressions” is basically
what you’re describing:
https://github.com/VerbalExpressions/SwiftVerbalExpressions
> On Jan 16, 2018, at 11:24 AM, Eneko Alonso via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Thank you for the reply.
Swift know it's const
and just allow it to be a let?
--
Rick Mann
rm...@latencyzero.com
___
swift-users mailing list
swift-us...@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
_______
swift
> On Jan 13, 2018, at 1:40 PM, Erica Sadun <er...@ericasadun.com> wrote:
>
>
>
>> On Jan 9, 2018, at 10:22 PM, Brent Royal-Gordon via swift-evolution
>> <swift-evolution@swift.org> wrote:
>> If we can't do this, I think we should call it someth
On Jan 15, 2018, at 11:01 PM, Xiaodi Wu via swift-evolution
<swift-evolution@swift.org> 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 protoc
com/keith_ray_resume_2014_long.pdf
> On Jan 16, 2018, at 11:24 AM, Eneko Alonso via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Digits could always be inferred to be numeric (Int) and they should always be
> “exact” (to match "\d"):
______
> On Jan 16, 2018, at 9:56 AM, Jon Gilbert via swift-evolution
> <swift-evolution@swift.org> 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 n
/.exactDigits(3) + "-").oneOrZero +
> /let routing: Int/.exactDigits(3) + "-" +
> /let local: Int/.exactDigits(4)
> ```
>
> In this model, the `//` syntax will only be used for initial binding and
> swifty transformations will build the final rege
> On Jan 14, 2018, at 09:36, Vladimir.S <sva...@gmail.com> wrote:
>
>
>
> On 12.01.2018 21:38, Jordan Rose wrote:
>>> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.o
aren't "top-level", but that's
not a rule or anything.
Jordan
>
> That said, I agree that the issue of source dependencies that might use this
> is a significant problem. IMO, that argues strongly for “unknown default:”
> producing a warning.
>
> -Chris
>
>&
other value")
> }
>
> //Now use syntax sugar
> switch myEnum.casesBelow {
> case .a: print("a")
> }
>
>
> This would look more intuitive to me than other solutions but I am not sure
> how much effort we need for this.
>
>
>
> On Mo
ting: Int/.exactDigits(3) + "-" +
/let local: Int/.exactDigits(4)
```
In this model, the `//` syntax will only be used for initial binding and swifty
transformations will build the final regex.
> On Jan 16, 2018, at 9:20 AM, Eneko Alonso via swift-evolution
> <swift-evolution@swift.org&g
Int, local: Int)>
Thanks,
Eneko
> On Jan 16, 2018, at 8:52 AM, George Leontiev via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Thanks, Michael. This is very interesting!
>
> I wonder if it is worth considering (for lack of a better word) *verbose*
>
> On Jan 13, 2018, at 18:26, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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 kno
te the addition of `UnicodeScalar` to the signature of `Regex`. Other
interesting signatures are `Regex<JSONToken, JSONEnumeration>` or
`Regex<HTTPRequestHeaderToken, HTTPRequestHeader>`. Building parsers becomes
fun!
- George
> On Jan 10, 2018, at 11:58 AM, Michael Ilseman via swift-evolution
>
> On Jan 15, 2018, at 2:40 PM, Stephen Canon via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
>> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> On 15. Jan 2018, at 23:55, Taylor Swift <kelvin1...@gmail.com> wrote:
>
>
>
> On Jan 15, 2018, at 3:30 PM, Karl Wagner <razie...@gmail.com
> <mailto:razie...@gmail.com>> wrote:
>
>>
>>
>>> On 14. Jan 2018, at 21:12, K
to build your own pure functions?
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
g on it), DecimalFloatingPoint become a standard library protocol,
and `0.1` become a "decimal literal" (with Float, Double, Float80, and
Decimal64/128 all conforming) as distinct from a "float literal" that we
could then restrict to hexadecimal (?and binary) floating-point litera
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
his thread to have, so if there is
any other conversation going on here then *that* is the different one. :-)
Nevin
_______
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
older Swift apps that aren’t rebuilt with a newer compiler)
essentially the two runtimes are designed to essentially ignore each other.
> On Jan 15, 2018, at 11:48 AM, Wallacy via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> This. I asked that already and they not
y chosen.
If you want to argue that, after we fix the buggy implementation of
> ExpressibleByFloatLiteral, then we should introduce a new protocol named
> ExpressibleByBinaryFloatLiteral, that might be a discussion worth having.
> But for the existing protocol, renaming it would not solve the und
leByBinaryFloatLiteral, that might be a discussion worth having.
But for the existing protocol, renaming it would not solve the underlying
issue.
Nevin
_______
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
ons or
enhancements are something that can wait.
Nevin
>
>
> On Mon, Jan 15, 2018 at 7:41 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
>> On Mon, Jan 15, 2018 at 4:24 PM, Nevin Brackett-Rozinsky via
>> swift-evolution <swift-evolution@swift.org>
com> wrote:
> On Mon, Jan 15, 2018 at 4:24 PM, Nevin Brackett-Rozinsky via
> swift-evolution <swift-evolution@swift.org> wrote:
>
>> Currently, the FloatingPoint protocol does not conform to
>> ExpressibleByFloatLiteral, whereas BinaryFloatingPoint does.
>
On Mon, Jan 15, 2018 at 4:24 PM, Nevin Brackett-Rozinsky via
swift-evolution <swift-evolution@swift.org> wrote:
> Currently, the FloatingPoint protocol does not conform to
> ExpressibleByFloatLiteral, whereas BinaryFloatingPoint does.
>
> The only explanation I can find f
> On Jan 15, 2018, at 3:40 PM, Stephen Canon <sca...@apple.com> wrote:
>
>
>
>>> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>> On 14. Jan 2018, at 21:12, Kelvin M
> On Jan 15, 2018, at 3:30 PM, Karl Wagner <razie...@gmail.com> wrote:
>
>
>
>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> This could work, but you’re also giving up all the nice Num
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
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/015691.html>
> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>
> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution
> <swift-evolution@swift.org> 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
a
valuable purpose going forward.
Nevin
On Sun, Jan 14, 2018 at 9:04 PM, Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:
>
>
> > On Jan 12, 2018, at 11:23 PM, Chris Lattner <clatt...@nondot.org> wrote:
> >
> > On Jan 12, 2018, at 4:43
Core.dylib, but if need to use a specific feature on
libswiftCore_4.1.dylib why not.
Em seg, 15 de jan de 2018 às 16:54, Jacob Williams via swift-evolution <
swift-evolution@swift.org> escreveu:
> Pardon my lack of knowledge in this area, but is there not also a 3rd
> option av
on this area of
Swift.
> On Jan 12, 2018, at 5:43 PM, Ted Kremenek via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Hi Chris,
>
> Instead of responding to each of your point bit-by-bit, I’ll try a different
> tactic to explain my reasoning — which may be
uot;other value")
}
//Now use syntax sugar
switch myEnum.casesBelow {
case .a: print("a")
}
This would look more intuitive to me than other solutions but I am not sure
how much effort we need for this.
On Mon, Jan 15, 2018 at 4:36 AM Vladimir.S via swift-evolution <
On Mon, Jan 8, 2018 at 4:29 PM, Ben Cohen via swift-evolution
<swift-evolution@swift.org> wrote:
> There exists in the standard library a type `DictionaryLiteral` that deserves
> naming re-consideration before we declare ABI Stability, because it’s
> confusingly misnamed
he impact in code size to the Standard
>> Library of removing Mirrors, but I hypothesize it is relatively modest (I
>> will look at verifying this hypothesis).
>
> I agree. The major motivation from my side isn’t the code size reduction, it
> is that we’ll have a better and brighter future with more clarity and less
> weird cruft left over - like the “DictionaryLiteral” type that sparked this
> whole thread. Have you looked at it? It’s crazy. :-)
I think a bright future is still possible in either scenario. From what I can
tell, if we don’t do anything, in the worst case there is some baggage left in
libswiftCore.dylib for the purposes of binary compatibility with older apps.
We still are left with the opportunity to deprecate those APIs in the future
even if we can’t rip those symbols out now.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
be
tuples of each case value and another literal (an enum case maybe) that
represents the availability metadata for that case.
Hooman
> On Jan 14, 2018, at 8:16 AM, Ben Rimmington via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> An alternative is a special #knownCases(of:)
(_:) static functions? i really only
use static constructors for initializers that have side effects
On Sun, Jan 14, 2018 at 6:36 AM, Karl Wagner <razie...@gmail.com> wrote:
>
>
> On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
&g
On 12.01.2018 21:38, Jordan Rose wrote:
On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution <swift-evolution@swift.org
<mailto:swift-evolution@swift.org>> wrote:
Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution <swift-evolution@swift.org
<mailto:swift-e
/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md>]
>
> I think this is generally reasonable, and none of the names offend me enough
>
> On 14. Jan 2018, at 06:04, BJ Homer via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> An Angle type already exists in Foundation; see Measurement. You
> could add some convenience methods in an extension pretty easily.
>
> import Foundation
>
&
> On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I do a lot of geometry and spherical-related work and i have never found an
> Angle type to be worth having. Always use radians. It’s what sin() and cos()
> take,
ability.
-g.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
on every angle
value? that really adds up when you’re converting 100,000s of lat-long pairs to
cartesian.
> On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> An Angle type already exists in Foundation; see Measurement. You
018, at 14:34, Anders Kierulf via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I also avoid using ! for negation when possible, and `toggle` or `invert`
> will be helpful, but in many cases I think the negative case is better
> expressed directly. For example, I f
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 rando
of
Foundation.Decimal on all supported platforms.
On Sat, Jan 13, 2018 at 9:07 PM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:
> Here is the code I use for percentage myself. (I incorrectly said I use a
> UInt64… I use a UInt32):
>
> ///Represents a percentage
(to: .radians).value
return sin(radians)
}
static var threeQuarterTurn: Angle {
return Angle(value: 0.75, unit: .revolutions)
}
}
let x = Angle.threeQuarterTurn
x.sine // -1
-BJ
> On Jan 13, 2018, at 9:31 PM, Erica Sadun via swift-evolution
> <swift-
https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721
<https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721>
and
* https://github.com/erica/SwiftGeometry
> On Jan 13, 2018, at 7:49 PM, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org> wrote:
>
&
ection (`collection.randomIndex()`) is more than
sufficient, assuming sufficient doc warnings that none of this is suitable for
encryption or gambling.
-- E
> On Jan 13, 2018, at 6:48 PM, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Basically, my point i
which (with all that complexity) still isn’t a uniform distribution!
Thats completely ignoring some of the finer issues you get with floating point
numbers as you certain transforms of a [0,1] distribution
-DW
> On Jan 13, 2018, at 7:41 PM, C. Keith Ray via swift-evolution
> <swift-ev
static func * (lhs:Num, rhs:Percentage)->Num {
return lhs * rhs.numValue
}
static func * (lhs:Percentage, rhs:Percentage)->Percentage {
return Percentage(lhs.decimalValue * rhs.decimalValue)
}
}
> On Jan 13, 2018, at 6:26 PM, Jonathan Hull via
, and it stops us from adding all of these angle-specific niceties.
Happy to provide code if there is interest…
Thanks,
Jon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
<- buy my book?
http://agilesolutionspace.blogspot.com/
twitter: @ckeithray
http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
> On Jan 13, 2018, at 6:15 PM, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Jan 1
ift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Jan 12, 2018, at 3:08 PM, Jordan Rose <jordan_r...@apple.com> wrote:
>>
>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's
>> point very specifically: if the compiler emit
nks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
> On Jan 12, 2018, at 8:22 PM, Nate Cook <natec...@apple.com> wrote:
>
> On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> I think we have different
ay random is used would likely lead to less opportunities for a trap than
>>> the other methods you mention.
>>>
>>>
>>> Letanyan
>>>
>>>> On 12 Jan 2018, at 04:39, Alejandro Alonso <aalonso...@outlook.com
>>>>
r a trap than
>>> the other methods you mention.
>>>
>>>
>>> Letanyan
>>>
>>>> On 12 Jan 2018, at 04:39, Alejandro Alonso <aalonso...@outlook.com
>>>> <mailto:aalonso...@outlook.com>> wrote:
>>>>
>
> On Jan 11, 2018, at 22:15, Chris Eidhof via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Hey SE!
>
> When we have a bunch of nested structs:
>
> struct Sample {
> var bar: Bar
> }
>
> struct Bar {
>
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
> <swift-evolution@swift.org> wrote:
>
> Big +1 to this. Getting these types out of the standard library and into a
>
On Jan 13, 2018, at 12:06 PM, Karl Wagner via swift-evolution
<swift-evolution@swift.org> wrote:
>
>> On 12. Jan 2018, at 20:54, Alejandro Martinez via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>&g
> On Jan 9, 2018, at 10:22 PM, Brent Royal-Gordon via swift-evolution
> <swift-evolution@swift.org> wrote:
> If we can't do this, I think we should call it something like `PairArray` or
> `KeyValueArray`
Or "KeyValueList", which avoids both "Dic
{
foo.doFoo()
}
doSomethingWithAFooable(0) // prints: I’m an Int
doSomethingWithAFooable("") // prints: I’m a String
Saagar Jha
> On Jan 13, 2018, at 01:45, Daryle Walker via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> From
> &l
1 - 100 of 28773 matches
Mail list logo
