on Thu Mar 24 2016, Guillaume Lessard <[email protected]> wrote:
>> * What is your evaluation of the proposal? > > I support this. Currently this requires the use of unsafeBitCast, which works > okay but is unwieldy. > I used unsafeBitCast to implement tagged pointers in a previous > exploratory project, and I think this proposal would improve > readability without being an inducement to recklessness. > > “bitPattern” is a decent label, but that is also used for the lossy > int-to-int conversions; No, we never use “bitPattern” for those conversions. We have “truncatingBitPattern” where conversions are lossy. > pointer-to-int casting may be different enough to warrant a different > label. “unsafeAddress” comes to mind, but may clash with the > similarly-named function. > >> * Is the problem being addressed significant enough to warrant a change to >> Swift? > > Yes. > >> * Does this proposal fit well with the feel and direction of Swift? > > Yes. > >> * If you have you used other languages or libraries with a similar >> feature, how do you feel that this proposal compares to those? > > Like uintptr_t, this requires an intentional step in order to do bit > operations on pointers. > >> * How much effort did you put into your review? A glance, a quick reading, >> or an in-depth study? > > A careful read and some experience trying this in swift. > > Cheers, > Guillaume Lessard > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
