+1000 to this. > On Jul 31, 2017, at 11:22 AM, Hooman Mehr via swift-evolution > <swift-evolution@swift.org> wrote: > > Maybe we need more than one level of standard library: The core (which is > most of what we have now (but maybe not all of it) and multiple opt-in > standard modules for hash functions, math, specialized data structures, etc. > >> On Jul 31, 2017, at 11:10 AM, Taylor Swift <kelvin1...@gmail.com >> <mailto:kelvin1...@gmail.com>> wrote: >> >> I’m not sure why only the stdlib is inlineable and specializable, but I >> believe it has something to do with ABI. I’m not an ABI expert though. I >> strongly disagree that a Swift Math library should be delegated to a third >> party. Math is “common” enough that there should really only be one >> “standard” implementation of it, under the direction of the Swift Project; >> we don’t want 5 competing third party Vector standards. >> >> On Mon, Jul 31, 2017 at 2:02 PM, Hooman Mehr <hoo...@mac.com >> <mailto:hoo...@mac.com>> wrote: >> I know. I hear you. I have some special arrangmnents to keep such things >> manageable, and I am not happy about how things stand right now. >> >> What I am hoping to open up stdlib special compiler mode to other >> (low-level) libraries and also letting such libraries gain optimizations >> similar to stdlib when included in a project. >> >> So, instead of putting things in stdlib, I want stdlib’s special privileges >> being made available to a certain category of third-party or internal >> modules. >> >> >>> On Jul 31, 2017, at 10:54 AM, Taylor Swift <kelvin1...@gmail.com >>> <mailto:kelvin1...@gmail.com>> wrote: >>> >>> Isn’t the point of standard inlineable library module to prevent the need >>> to copy and paste code like this into every project? Currently I have a >>> “math.swift” file I copy and paste into all of my projects, and since I >>> occasionally update it, there exists about 15 different versions of it >>> floating around, so I know this is not a sustainable practice. >>> >>> On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr <hoo...@mac.com >>> <mailto:hoo...@mac.com>> wrote: >>> I prefer an approach that preserves how I am used to seeing math >>> expressions. I use this myself: >>> >>> protocol FloatingPointMath: FloatingPoint >>> { >>> static func sqrt(_ value: Self) -> Self >>> >>> static func sin(_ value: Self) -> Self >>> static func cos(_ value: Self) -> Self >>> static func tan(_ value: Self) -> Self >>> static func asin(_ value: Self) -> Self >>> static func acos(_ value: Self) -> Self >>> static func atan(_ value: Self) -> Self >>> >>> static func ln(_ value: Self) -> Self >>> static func log(_ value: Self, base: Self) -> Self >>> static func pow(_ value: Self, exponent:Self) -> Self >>> static func exp(_ value: Self) -> Self >>> } >>> >>> It does not pollute the global namespace and gives nice contextual >>> auto-completion. And I don’t want it in the standard library: I only add >>> the file when I need it. (it is not a separate module for optimization >>> reasons). >>> >>>> On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> >>>> >>>> On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev >>>> <adrian.zuba...@devandartist.com <mailto:adrian.zuba...@devandartist.com>> >>>> wrote: >>>> I’m not sure how I would feel about this. To be honest I’d avoid such >>>> additional changes from the stdlib, because they really don’t belong >>>> there. Instead some `Math` module/package would be a better fit than >>>> clustering everything into stdlib until we end up also adding UI stuff. >>>> >>>> Furthermore, I don’t think a function would make any sense here. It really >>>> should be a computed property. >>>> >>>> >>>> >>>> I think a standard Math module would be a good idea, but only if it >>>> benefits from the same inlining and specialization as the standard >>>> library. Also squareRoot() should be moved to the Math module if it is >>>> ever created. >>>> >>>> Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution >>>> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: >>>> >>>>> How would people feel about adding a protocol >>>>> >>>>> protocol MathFloatingPoint:FloatingPoint >>>>> { >>>>> func sin() -> Self >>>>> func cos() -> Self >>>>> func tan() -> Self >>>>> func asin() -> Self >>>>> func acos() -> Self >>>>> func atan() -> Self >>>>> >>>>> func ln() -> Self >>>>> func log(base:Self) -> Self >>>>> func pow(exponent:Self) -> Self >>>>> func exp() -> Self >>>>> } >>>>> >>>>> to the standard library? Float and Double would then be made to conform >>>>> by default using Swift implementations instead of having to import Glibc >>>>> / Darwin and writing the extensions, depending on platform. >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
