1. 18

  2. 15

    I am sincerely, profoundly impressed by how the super-high-abstraction solution cleanly compiles down to basically the most optimal assembler I’d write by hand. That’s nuts.

    1. 1

      I’m not sure I follow. Isn’t all of that conversion code the same as a reinterpret_cast?

      1. 3

        I guess that depends on whether the bytes are copied, or not.

        In general, it’s disappointing that languages created in the 21st century still convert between different number types by “casting”.

        1. 1

          Also the order. Unless I’m misremembering, reinterpret_cast doesn’t do anything about byte ordering. This does.

      2. 0

        I am amazed that most optimal assembler that I’d write by hand must be represented by such a super-high-abstracted solution.

        So this is something you would have to do when facing file IO for non-native formats? I have not used Swift, but I am guessing they have a preferred file IO api with Swift-specific abstractions and/or formatting?

        1. 5

          To be clear, it doesn’t have to be represented by such a high abstraction; there are some much simpler ones than that final extension that I assume we’re both referencing, and they’re both more common approaches and likely generate identical, or near-identical, assembler. The fun thing about the super-high abstraction is you get the benefits of having a pile of custom conversion functions without actually writing them.

      3. 2

        This should be tagged swift.