Reserve more numeric types

[emberian]

No description provided.

[sinistersnare]

Does this include uints?

[huonw]

I'm not really sure this is necessary. Built-in types like int are not keywords now, and 1f128 doesn't tokenise, so AFAICT there no backward compatibility concern from either of those.

Does rust plan on adding support for arbitrarily sized primitives? If so how will this work with it?

What do you mean by this/how does this relate?

[huonw]

Does this include uints?

There is explicit mention of u128.

[sinistersnare]

@huonw Yes i misread, but i reread and saw, and deleted my comment, but you were too quick!

Also, his grammar in the detailed design section does not mention uints.

[emberian]

I'm not really sure this is necessary. Built-in types like int are not keywords now, and 1f128 doesn't tokenise, so AFAICT there no backward compatibility concern from either of those.

They are not keywords, but they are built-in in the type grammar, and you cannot introduce a new built-in without breaking code that used that identifier. 1f128 will not parse, but it does tokenize, as LIT_FLOAT(1f) LIT_INTEGER(128).

I will update to clarify.

[emberian]

(uints were an oversight)

[sinistersnare]

I figure so, I just meant to point it out.

[huonw]

1f128 will not parse, but it does tokenize, as LIT_FLOAT(1f) LIT_INTEGER(128).

Ah, I was mistaken, sorry. In any case, 1f is no longer a valid float literal.

[emberian]

Actually, this is entirely unnecessary.

[sinistersnare]

@cmr care to explain?

[alexchandel]

It's more than conceivable that we will need u128, i128, and f128, and maybe even f16.

Are you sure these are already in the grammar?

[emberian]

This is legal today:

struct int;
struct f128;

Adding a built-in f128 would not break any code (modulo bugs in re-using those identifiers, which are just bugs in resolve), redefinitions using that name would just shadow it, as would imports etc.

[Ericson2314]

On the flip side, should any numeric types parse, let alone tokenize specially?