I’ve been reading about Elements RTL. The specific example described in the docs regards a Dictionary class.
If my intent is to write console apps for macOS and Windows in Swift - is there any reason to use the RTL Dictionary class over Swift’s native Dictionary class in my shared projects? Presumably there is a Swift Dictionary class available on Windows with Swift?
Am I misunderstanding RTL’s purpose?
No good reason, aside from that you prefer one API over the other. Swift’s dictionary also is a value type, which has many usable implications that (IMHO) make it less desirable to use for most cases — but that’s just me, personally).
Also, Elements RTL’s types map (where applicable) to platform-native types (e.g. Dictionary to NS(Mutable)Dictionary, List to NS(Mutable)Array, etc. So these can be toll-free bridged to Cocoa APIs (similar to the discussion we had about Strings in the other thread), Since SBL’s Array and Dictionary types are value types, small overhead conversions are needed when passing them from/to Cocoa APIs.(which are still going to be more lightweight than Apple Swift’s, but they are there).
There’s certainly some overlap, yes,
Swift Base Library (SBL) is there not provide some of the common types that Apple Swift has, in way that work as closely to how Apple’s versions work (for better, or for worse). (while it can be used from all languages, it’s not really designed for that with how the APIs look and feel).
Elements RTL is there to provide common base functionality for all of Elements languages, and all platforms using the same set of unified OOP APIs.
By nature, there’s some duplication there, with some things covered by both SBL and Elements RTL, in different ways*.
(* right now, SBL is implemented without reliance on Elements RTL (you don;‘t have to link in both), which also means there’s a certain amount of code duplication, as well; in the long run, I want to rework SBL to leverage Elements RTL under the hood, alleviating the need to have per-platform implementation in SBLs’ code and just have SBL defer to the abstractions provided in RTL2, under the hood.