Is there really any reason to use Bytes instead of Slice(UInt8)?

@RX14 I guess it's the same reason that brought alias Bytes into being. I see it twofold:

• Descriptiveness: Bytes communicates clearer message than Slice(UInt8)
• Speed: Bytes is 7 characters less than Slice(UInt8)

We should resolve #3551 to avoid changing this again I think. Just in case Bytes turns to Binary as @kostya suggested.

@bcardiff IMO it'll be easier to change it afterwards just by find-and-replace Bytes to Binary. Right now there are both forms present throughout the codebase.

What happens if we eventually decide to add a BinaryTree type to the standard library?

The Bytes = Slice(UInt8) alias was introduced as a convenience. Since there are some doubts on the chosen name, we should stick to the actual type, that is Slice(UInt8), instead of the alias for the time being.

If we currently use a mix, maybe we should change the occurrences of the Bytes type to the original type, instead.

I actually like Bytes: it's short and clear, and I honestly don't see it going away just because we have String#bytes. My comment about BinaryTree was about saying that if we eventually chose the name Binary instead of Bytes, it will be odd to say "Oh, but now we have BinaryTree and it's not a tree of Binary, isn't this an inconsistency? And String#bytes isn't very useful, just two occurrences in the standard library, vs. more than 100 of Bytes.

Like in Esperanto there's the suffix "-eg-" which means "big", so you can say "domo" = "house" and "domego" = "mansion". But then you have "kolo" = "neck" and "kolego" = "big neck", but "kolego" is also "collegue". But they didn't start renaming suffixes or words when they found this out, it's honestly not a big deal and I was able to speak Esperanto despite of this small inconsistency 😸

This PR will get outdated soon due to many occurrences of Slice(UInt8) in the code so it would be great to get it merged rather sooner than l8r :)

Personally I think that alias is much more useful for naming union types. Calling it Bytes hides the fact that its a slice and you can call slice methods on it. You know it's a slice, I know it's a slice but its one more thing for a newcomer to learn.

Using Slice.empty is good though.

@RX14 Learning about Bytes being an alias for Slice(UInt8) IMO is not too much to require from newcomers and afterwards makes for way smoother experience with reading code. I'd argue that learning that Slice(UInt8) is a Crystal way to handle byte slices is another requirement which, after you've learned about Bytes, becomes more clear.

@asterite any action here? :)

@Sija Actually, Knowing Bytes is a Slice(UInt8) means that they can look up Slice and UInt8 in the docs, however Bytes has no documentation of its own.

@RX14 and what about this? There are links there to both: Slice & UInt8 :)

Personally, my view on alias is the same as @asterite's view on aliasing methods: aliases mean more things to learn and they erode simplicity.

I think that the only valid use for alias is naming union types.

In my eyes Bytes as an alias is more like a composition of Slice with UInt8 being closer to an idiom than alias. Aliased methods OTOH are just different names for exactly the same set of properties.