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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev >> <[email protected] <mailto:[email protected]>> >> 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 >> ([email protected] <mailto:[email protected]>) 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
