Add `Float16`

I personally find it rather hard to believe this would actually confuse anyone who is capable of working directly with Metal.

6 Likes

I'd say many developers are "capable", but that's beside the point. The point is, if we are trying to avoid "doubt and confusion" by not making a typealias (which by the way, Xcode will happily tell you is a typealias if you were really unsure), in certain cases that could actually be more confusing to some people.

And, as I have said before, it's not a big deal if Half isn't included in this proposal, I'll just make the alias myself. But the idea that somehow a typealias is too confusing doesn't hold much water. If it did, why have typealiases at all?

1 Like

I guess there are even people who would happily discard this feature ;-) — but I personally have two major use cases:

  • A shortcut for a wordy type (especially function signatures)
  • When a type might be exchanged with an alternative

Often it's a combination of both reasons, but it's always in an restricted context. Actually, I couldn't name a single typealias in the stdlib...
Looking at other frameworks, there is CGFloat, but even that is its own type.
It would have some advantages if CoreGraphics had used a typealias, though, and I think it's fine to define Half in certain contexts — but I would not want two names for a single type in the stdlib.

Here's an ironic one:
typealias Float32 = Float

Imho that is an argument for typealias Float16 = Half...

2 Likes

CChar is one. And it causes all sorts of confusion because this:

let a = CChar("a")

...doesn't do what you might hope.

1 Like

Narrator:

// or UInt8 on some systems
let a = Int8("a") // Int8?.none or nil
1 Like

I agree that to be consistent would be to typealias Float16 as Half. I also agree with Ben Cohen's response against nicknames.

1 Like

Do note that that type alias has this comment on top of it:

6 Likes

That makes more sense to me as well - the names of our number-types all look rather archaic:
There's nothing wrong with int and float in isolation, but schemes like double and long don't scale well.
In the long run, I hope this will all be replaced with something like Int<Size> and Float<ExponentSize, FractionSize> (with some aliases for common types).

However, when the status quo is to have aliases like Float64 (which afaik is not nearly as common as double), it seems odd to ignore a popular* name like Half completely.

* according to other posts in this thread - I have no idea about actual prevalence in the wild

1 Like

Where might one begin looking in the typechecker to see if this is still a bug?
I'm happy to try.

As a newbie here, it seems the intended * implementation of the current types is typealias Float = Float32 and typealias Double = Float64

If Float is corrected to Float32 (with the added typealias above), then the name Float16 would be consistent. A typealias to Half could be added if desired (see the discussion above), but that decision that is well above my pay grade / could be made later.

In either case, am I able to look into the typechecker issue? (i.e. might I be jumping in too deep?)
Thanks :slight_smile:

* per the FIXME in the gist mentioned by @Dante-Broggi

(bold added for emphasis for what I'm going on about in my unnecessary aside)

IIRC unfortunately it is not this easy to specify, as Float80 has a different fraction format with an explicit leading '1'.

Don't worry - in my hypothetical future, default values for generic parameters are already well established ;-)

But to return to the near future:
I don't think there is any real resistance against adding a floating point type with 16 bits, and while there are strong preferences, afaics no one really insists on a certain name.
The thread is nearly a year old, and imho it's time to move to the next stage.

2 Likes

Correct, as far as I’m concerned, it is really not a problem if the Half typealias is omitted. I think I’ve made decent arguments for it to be included, but it’s a very small thing and truly not that important to me.

Years ago when I first discovered I had to write all support for Float16s myself when talking to OpenGL shaders I was all :frowning:

Then when I ported everything to Swift I was like oh boy I bet they support Float16 but then I was all :frowning:

Then when I ported the OpenGL code to MetalSL I was all surely the Metal APIs support Float16 but then I was all :frowning:

So this proposal is all :slight_smile:

13 Likes

The emojis really tell a story here.

4 Likes