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] Core Team vs Random number API discussion

ss it really doesn’t matter how extensible it is and that the focus should be to get something that *most* people will be able to use easily. > On Wed, Dec 6, 2017 at 18:34 Jacob Williams via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: &

Re: [swift-evolution] Core Team vs Random number API discussion

I agree with this decision, but I would also add the provision that the random number API be designed in such a way that those with special crypto needs can easily extend the existing random number framework to meet their needs. (Specify their own seed, use their own crypto implementation,

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 11:05 AM, Dave DeLong via swift-evolution > wrote: > > Hi Chris, > > We do the Swift integration with Objective-C via modules. Why wouldn’t that > approach work with Python? Or if it would, why would we favor this dynamic > member lookup over

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

I’ve been going back and forth on whether I’m for or against the current revision of the proposal and I’d have to say that I am in favor of it as is for the following reasons (many of which have already been stated): It was stated early on in this proposal that Python is not going to be given

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

Huge +1 Dealing with path manipulations via Foundation is a real pain on Linux. I end up using a lot of C code from Glibc. And random support is another pain point. There are tons of uses for a non-std library, however, i would like to see python style imports (if possible) to avoid importing a

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

> On Nov 6, 2017, at 5:29 PM, Kelvin Ma via swift-evolution > wrote: > > hot take: i use the second one a lot but only because i always forget the > first one exists. So I type the = nil just to “be sure”. > Same here! I just changed a bunch of code since I’d

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

I agree with Dave’s assertion that this should be in a separate Random library. Not every project needs random numbers and there could possibly be a SecureRandom that exclusively uses CSPRNGs for it’s functionality. I also agree that trapping is not a preferred behavior. Optionals are slightly

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

ing/brainstorming. > On Sep 8, 2017, at 3:03 PM, Jacob Williams via swift-evolution > <swift-evolution@swift.org> wrote: > > Huge +1 to stdlib (or even Foundation) random number generator. I’ve worked > with random numbers on both Linux and macOS/iOS and have found myself annoyed

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

Huge +1 to stdlib (or even Foundation) random number generator. I’ve worked with random numbers on both Linux and macOS/iOS and have found myself annoyed with the lack of easy random number generators. It seems that implementing a pure Swift RNG would be an obviously good addition to the

Re: [swift-evolution] (core library) modern URL types

There’s also a library somewhat similar to PathKit called FileKit (https://github.com/nvzqz/FileKit ). FileKit has some functionality I’m not sure how I feel about, such as different types based on the type of data in the file. It also uses a lot of Foundation

Re: [swift-evolution] Swift source mentorship program

A Swift developer has actually started a blog series about the swift compiler. The links to his post were posted in one of the evolution topics a little while ago. The series is incomplete, but it gives a lot of explanations about the various parts of the swift compiler.

Re: [swift-evolution] Draft: Regular Expression in Swift

Disclaimer: I am not well versed in the various complexities of regex implementations. That being said, I would very much like to see better regex support in Swift. Preferably one that is easier to pick up than the NSRegularExpression of ObjC and possibly as easy to start using as python or

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

There’s also a PureSwift organization of GitHub that has several Swift PM packages built specifically with Linux support in mind https://github.com/PureSwift It looks like it’s along the lines of SwiftBreezy, but it hasn’t died out…yet. At the same time, this may

Re: [swift-evolution] Change 'for in' expression to for [] { (item) in ... }

This change would also make it so that for loops follow the same format as all other closures with variables. The downside is that this would break a TON of code. I don’t think that the amount of code this breaks would be worth the consistency. And as Alex mentioned, it is possible through

Re: [swift-evolution] [idea] errors in properties

I’d give my +1 to support this as I’ve wished at one time or another that I could throw in the get, set, willSet, or didSet. Would this be something a proposal should be written up for when the Swift 5 reviews begin? > On Jul 25, 2017, at 2:55 PM, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] JIT compilation for server-side Swift

Pardon my lack of knowledge about JIT compilation, but does this open the realm of possibilities to a client-side swift that would allow web developers to write swift code rather than javascript? > On Jul 10, 2017, at 10:40 AM, Younes Manton via swift-evolution >

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

I have been persuaded that extending the capabilities of the current ?? operator has far more advantages than adding a new limited !! operator. While I initially did not like the usage of the generally-assumed-safe ? for throwing operations, the clarity provided by having to explicitly state

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

ring the sentiment of !. It would feel more swifty, and you’d get the clarity of knowing that !! is an unsafe operation and you’d know exactly what kind of error is being thrown. And then ?? could be left as-is and only used for default values. > > On Wed, Jun 28, 2017 at 8:52 AM Jacob W

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

I feel that the !! operator would be necessary for indicating that if this fails then something went horribly wrong somewhere and we should throw the fatalError. This allows the inclusion of optimizations using -Ounchecked and is clear that this is an operation that could result in a runtime

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

+1 to Adrians implementation. While I like the sugar of both, I don’t think the operator should necessarily always cause a fatalError. Maybe we could use both the !! For some kind of fatal error and Adrians !? To just use @noreturn to leave the current function. > On Jun 27, 2017, at 11:29 AM,

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

gt; > or with any similar compatibility typealiases. > >> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> +1 from me. >> >> There have been t

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

+1 from me. There have been times I’ve wanted to subclass an object (such as String) but since it is a non-class, non-protocol type you can only extend Strings existing functionality which adds that same functionality to Strings everywhere. It would be nice if we could either extend type

Re: [swift-evolution] [Pitch] Localized Swift Frameworks

+1 While I think this could be an incredibly useful feature that would make teaching coding to people much easier since they no longer need to learn English words at all, I think this can get really tricky when you consider autocomplete and all of the work an IDE has to do to identify the