Name for the field element type in Cairo 1.0

[AbdelStark]

Description

Dear Cairo builders, we need your opinion on the name of the field element type in Cairo 1.0. So far, we always have used the term felt to design the basic type in Cairo. With Cairo 1.0 and Sierra, we want to give more flexibility and adaptability to the language, hence we anticipate potential future changes to the basic field element type we use (i.e use goldilocks instead of the current prime). We also want to make explicit at a given time what field element is used, and we believe it should be reflected in the name of the type.

[enitrat]

I would stay away from f252 as it can be mistaken for floating-point numbers.

[milancermak]

I don't like having 252 in the name itself, because it cannot hold all the values that fit into 252 bits, i.e. 2**252 > 2**251 + 17 * 2**192 + 1

[martriay]

it can't?

[martriay]

oh right there was some space reserved for something, no? i can't find it in the docs

[milancermak]

I think you're right, there was something related to addresses, but also can't remember or find the details.

However what I meant with the comment was that the max value that fits into 252 bits is greater than the prime so it would just wrap around ((2**252 - 1) % prime). So while we need 252 bits to store the prime, not all values are "available" which is in contrast with other primitive types like u128.

[gaetbout]

Why not simply felt:
1_felt
42_felt
?

[AbdelStark]

because as I explained in the description if at some point we change the prime to goldilocks for example it will be problematic

[gaetbout]

To make sure I understand correctly, is it about changing the felt in variables:
fn some_fn(some_felt: felt, some_other_felt: felt252);
Or in creating a felt:

1_felt
42_felt

Or somewhere else?

[Eikix]

i feel as though usual types are characterized by the number of bits they fit,
u8, u32 etc.

here, we use bits for our usual felt type 251 or 252 for convenience, but the field itself characterizes the felt.

since fields have distinct names, they could be used as prefixes or suffixes.

e.g.

felt_gl for field element on goldilock

or simply felt, always, and you declare use goldilocks::felt at the top of your file.

[bbrandtom]

The problem is that we don't have a "known" name for the field we currently use in Cairo.

[Eikix]

i guess you could name it the starkware field?
or it could be the felt_std as it was the first

felt_std, felt_gold or felt_gl , etc. but it does add an underscore in the type, which is quite ugly.
I guess namespacing the type feels okay to me

std::felt
goldilocks::felt, etc

[ericnordelo]

Rust convention is keeping things minimal (fn, u32, pub, etc...), that's why I like fe252 over felt252. Agree f252 seems confusing (f is used for float)

[Pet3ris]

fe252 is my pick because it's a shorthand for felt/field element. Rust uses fX for floating-point so I agree we should avoid this.

[Eikix]

is it possible that two fields both use a prime that is close to 252 bits? if so, then this name allows for "naming collision"

[AbdelStark]

We decided to go with felt252, as this is the winner option in the poll. In the future we will add aliasing capabilities so that the developer will have the freedom to choose what suits best. Thanks a lot for your contribution.

[mkaput]

In the future we will add aliasing capabilities so that the developer will have the freedom to choose what suits best.

Please don't do that, people will start fighting over taste differences. I think it'd be better to enforce one convention 🤔

[AbdelStark]

Noted @mkaput thanks for the input

[TotalPizza]

Do I see correctly that the decision has been made 4h after voting started?
Kinda quick, no?

[AbdelStark]

Yeah sorry we were in a rush for StarkNet 0.11. Next time we will make sure to consult earlier

[AbdelStark]

#Linux
grep -rl --exclude-dir=.git --include \*.cairo felt . | xargs sed -i 's/felt/felt252/g'

# Mac OS
grep -rl --exclude-dir=.git --include \*.cairo felt . | xargs sed -i "" -e 's/felt/felt252/g'