New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Renaming int/uint #464

Closed
wants to merge 6 commits into
base: master
from

Conversation

Projects
None yet
@1fish2

1fish2 commented Nov 13, 2014

This RFC adopts Daniel Micay's suggestion to replace RFC: int/uint portability to 16-bit CPUs with a single-purpose RFC to just rename int/uint.

This RFC assumes a fixed-size integer type will become the type inference fallback and thus the language's "default integer type" and, in turn, heavily used in tutorials and libraries. See RFC: Change integer fallback RFC to suggest i32 instead of int as the fallback.

What changed since Daniel's original RFC on this issue?

  • Interest in restoring integer type inference fallback, but to a fixed-size integer.
  • Interest in the Rust Guide using mostly a fixed-size integer instead of pointer-sized integers.
  • Mickaël Salaün found and listed some int/uint portability bugs.
  • Gábor Lehel wrote an RFC for checked arithmetic, making that an independent issue.
  • Lots more discussions about integer type names. (See the RFC for links.)

While the new choice of names might be considered bikeshedding or not, moving away from long-held expectations on int/uint set by other programming languages is a usability issue.

1fish2 pushed a commit to 1fish2/Rust-rfcs that referenced this pull request Nov 13, 2014

@Kimundi

This comment has been minimized.

Show comment
Hide comment
@Kimundi

Kimundi Nov 13, 2014

Member

Another possible naming option would be iptr and uptr.

Member

Kimundi commented Nov 13, 2014

Another possible naming option would be iptr and uptr.

@tbu-

This comment has been minimized.

Show comment
Hide comment
@tbu-

tbu- Nov 13, 2014

Contributor

cc me

Contributor

tbu- commented Nov 13, 2014

cc me

@cmr

This comment has been minimized.

Show comment
Hide comment
@cmr

cmr Nov 13, 2014

Member

I disagree with the names index and uindex because the uindex type is the one that would be used for indexing, not index! I also think index is far too good of an ident to sacrifice as the keyword for this purpose. I think uptr and iptr are the best choice that have the same name, but index and ptrdiff would be better type names I think, if we're willing to take the index keyword for this. If we had "generic numeric literals", these types wouldn't even need to be in the language, and could instead just be regular types in libcore.

Member

cmr commented Nov 13, 2014

I disagree with the names index and uindex because the uindex type is the one that would be used for indexing, not index! I also think index is far too good of an ident to sacrifice as the keyword for this purpose. I think uptr and iptr are the best choice that have the same name, but index and ptrdiff would be better type names I think, if we're willing to take the index keyword for this. If we had "generic numeric literals", these types wouldn't even need to be in the language, and could instead just be regular types in libcore.

@tbu-

This comment has been minimized.

Show comment
Hide comment
@tbu-

tbu- Nov 13, 2014

Contributor

@cmr I propose we delay the bikeshedding until this RFC is agreed upon (modulo the naming).

Contributor

tbu- commented Nov 13, 2014

@cmr I propose we delay the bikeshedding until this RFC is agreed upon (modulo the naming).

@gioele

This comment has been minimized.

Show comment
Hide comment
@gioele

gioele Nov 13, 2014

@tbu-: I am confused, what is to be agreed up if not the naming? The RFC states the proposal as

Rename the pointer-size integer types from int and uint to index and uindex to avoid misconceptions and misuses. They aren't the default types you're looking for.

gioele commented Nov 13, 2014

@tbu-: I am confused, what is to be agreed up if not the naming? The RFC states the proposal as

Rename the pointer-size integer types from int and uint to index and uindex to avoid misconceptions and misuses. They aren't the default types you're looking for.

@vks

This comment has been minimized.

Show comment
Hide comment
@vks

vks Nov 13, 2014

One issue that is not discussed in the RFC is that uindex will be also the type used for sizes. While I personally don't care, people might find counterintuitive that Vec.len returns a uindex.

vks commented Nov 13, 2014

One issue that is not discussed in the RFC is that uindex will be also the type used for sizes. While I personally don't care, people might find counterintuitive that Vec.len returns a uindex.

@gioele

This comment has been minimized.

Show comment
Hide comment
@gioele

gioele Nov 13, 2014

Ranges have the same problem: it seems unnatural to have uindex as the type of i in

for i in range(0u, 10) {
    println!("i = {}", i);
}

gioele commented Nov 13, 2014

Ranges have the same problem: it seems unnatural to have uindex as the type of i in

for i in range(0u, 10) {
    println!("i = {}", i);
}
@vks

This comment has been minimized.

Show comment
Hide comment
@vks

vks Nov 13, 2014

@gioele The RFC assumes that a fallback to i32 will be implemented, so you don't need that annotation. We might consider renaming the suffixes though.

vks commented Nov 13, 2014

@gioele The RFC assumes that a fallback to i32 will be implemented, so you don't need that annotation. We might consider renaming the suffixes though.

@Thiez

This comment has been minimized.

Show comment
Hide comment
@Thiez

Thiez Nov 13, 2014

I have to agree with cmr here, it would be confusing if the index type was not actually used for indexing. I also quite like uptr and iptr, with index and ptrdiff as a second choice.

Thiez commented Nov 13, 2014

I have to agree with cmr here, it would be confusing if the index type was not actually used for indexing. I also quite like uptr and iptr, with index and ptrdiff as a second choice.

@l0kod

This comment has been minimized.

Show comment
Hide comment
@l0kod

l0kod Nov 13, 2014

I would also add the argument that the renaming process would be the good and probably only time to spot future bugs before they appear.

There is also the question about integer suffixes i and u. They must change (or disappear) accordingly to the int/uint, otherwise the bugs related to this names will surely remains in the existing code.

A good example of using uindex (or uptr) and not index (or iptr) should help too: object indexing and object length (not sure anymore)?

l0kod commented Nov 13, 2014

I would also add the argument that the renaming process would be the good and probably only time to spot future bugs before they appear.

There is also the question about integer suffixes i and u. They must change (or disappear) accordingly to the int/uint, otherwise the bugs related to this names will surely remains in the existing code.

A good example of using uindex (or uptr) and not index (or iptr) should help too: object indexing and object length (not sure anymore)?

@arcto

This comment has been minimized.

Show comment
Hide comment
@arcto

arcto Nov 13, 2014

I think too that the intand uint names should be changed. index however, as pointed out by @cmr, is too valuable as a descriptive identifier name. Change the keywords, but to some other names.

arcto commented Nov 13, 2014

I think too that the intand uint names should be changed. index however, as pointed out by @cmr, is too valuable as a descriptive identifier name. Change the keywords, but to some other names.

@l0kod

This comment has been minimized.

Show comment
Hide comment
@l0kod

l0kod Nov 13, 2014

Some discussions about the naming are in the forum and in #161.

Some arguments found there :

  • One problem with names like index, size, and offset, besides the plain lack of familiarity, is that it might not be immediately obvious that this is an integer type at all. (from @glaebhoerl)
  • That may be a good point to have an unfamiliar type name.
  • Maybe if we took off that implicit constraint, then we could arrive somewhere interesting, like uaddr and ioffset. Since, you know, the signed case arises from pointer arithmetic and thus it makes sense to talk about as a relative offset versus the unsigned being an absolute address. Of course, going down that road might lead one to them attempt to encode rules in the types like uaddr + ioffset -> uaddr and make addition of uaddr itself illegal, while uaddr - uaddr -> ioffset. Kind of funny looking. (from @pnkfelix)
  • A usize will be more explicit than the uaddr (a size must always be positive) and is more abstract than an address. A ulength or ulen type make sense too.
  • isize and usize are short enough, get the point across, are familiar to those coming from C, and match the prefixes used for other integer types. (from @rkjnsn)
  • Calling them isize/usize wouldn't really be correct. The maximum object size (including for arrays) needs to be capped 1 bit lower than the pointer size. The types are defined as having the same number of bits as pointers, not as a way of measuring sizes. (from @thestinger)

That said, I like the iptr and uptr because they refer directly to the (variable) pointer length like i32 refer to the 32 bits length.

l0kod commented Nov 13, 2014

Some discussions about the naming are in the forum and in #161.

Some arguments found there :

  • One problem with names like index, size, and offset, besides the plain lack of familiarity, is that it might not be immediately obvious that this is an integer type at all. (from @glaebhoerl)
  • That may be a good point to have an unfamiliar type name.
  • Maybe if we took off that implicit constraint, then we could arrive somewhere interesting, like uaddr and ioffset. Since, you know, the signed case arises from pointer arithmetic and thus it makes sense to talk about as a relative offset versus the unsigned being an absolute address. Of course, going down that road might lead one to them attempt to encode rules in the types like uaddr + ioffset -> uaddr and make addition of uaddr itself illegal, while uaddr - uaddr -> ioffset. Kind of funny looking. (from @pnkfelix)
  • A usize will be more explicit than the uaddr (a size must always be positive) and is more abstract than an address. A ulength or ulen type make sense too.
  • isize and usize are short enough, get the point across, are familiar to those coming from C, and match the prefixes used for other integer types. (from @rkjnsn)
  • Calling them isize/usize wouldn't really be correct. The maximum object size (including for arrays) needs to be capped 1 bit lower than the pointer size. The types are defined as having the same number of bits as pointers, not as a way of measuring sizes. (from @thestinger)

That said, I like the iptr and uptr because they refer directly to the (variable) pointer length like i32 refer to the 32 bits length.

@vks

This comment has been minimized.

Show comment
Hide comment
@vks

vks Nov 13, 2014

I like the possibility of using different types for an address and a size, even if they are the same primitive type. It solves the problem that uptr/uaddr and usize are both "wrong" if used for both cases.

It might make simple loops that index all elements of a vector annoying if there is no implicit conversion though. (The highest possible address is the size - 1.)

vks commented Nov 13, 2014

I like the possibility of using different types for an address and a size, even if they are the same primitive type. It solves the problem that uptr/uaddr and usize are both "wrong" if used for both cases.

It might make simple loops that index all elements of a vector annoying if there is no implicit conversion though. (The highest possible address is the size - 1.)

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Nov 13, 2014

@vks: It's not correct to use int / uint for sizes in all cases. It only works when the size is bounded by the address space. For example, bit vectors and arrays of zero size types are artificially restricted by the use of uint - which is not necessarily a bad thing, but it's something to be aware of (it has been a pervasive soundness issue).

thestinger commented Nov 13, 2014

@vks: It's not correct to use int / uint for sizes in all cases. It only works when the size is bounded by the address space. For example, bit vectors and arrays of zero size types are artificially restricted by the use of uint - which is not necessarily a bad thing, but it's something to be aware of (it has been a pervasive soundness issue).

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Nov 13, 2014

I think we can separate the issue of whether they should be renamed to something to do with pointers / sizes from bikeshedding the specific names that are chosen. I strongly support the RFC, although I would prefer uptr / iptr as the specific names. It's nice that both names have a sign prefix like the fixed-size integer types, and the definition is extremely clear. I still think the alternative names like intptr / uintptr and index / uindex would be a significant improvement over the status quo.

thestinger commented Nov 13, 2014

I think we can separate the issue of whether they should be renamed to something to do with pointers / sizes from bikeshedding the specific names that are chosen. I strongly support the RFC, although I would prefer uptr / iptr as the specific names. It's nice that both names have a sign prefix like the fixed-size integer types, and the definition is extremely clear. I still think the alternative names like intptr / uintptr and index / uindex would be a significant improvement over the status quo.

@vks

This comment has been minimized.

Show comment
Hide comment
@vks

vks Nov 13, 2014

@thestinger I agree that this is an artificial limitation, but I really don't see an alternative at the moment, because there is no u64+3 or bigint in Rust. If that is really a problem in practice, it is possible to implement a BigVec that has a bigint as size.

I also like uptr and iptr the most.

vks commented Nov 13, 2014

@thestinger I agree that this is an artificial limitation, but I really don't see an alternative at the moment, because there is no u64+3 or bigint in Rust. If that is really a problem in practice, it is possible to implement a BigVec that has a bigint as size.

I also like uptr and iptr the most.

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Nov 13, 2014

It's a reason not to name the types isize / usize because they're really defined in terms of the address space size. The maximum object size may be significantly lower, although the theoretical upper bound is determined by removing 1 bit from the address space size.

thestinger commented Nov 13, 2014

It's a reason not to name the types isize / usize because they're really defined in terms of the address space size. The maximum object size may be significantly lower, although the theoretical upper bound is determined by removing 1 bit from the address space size.

Feedback. First agree to rename then pick the names.
Incorporate most of the feedback so far.

The first aim is to decide to rename `int` and `uint`. The second step is to pick the specific names.

I see the second step as usability design, not really bikeshedding, but it is second. A quick-and-dirty usability test could be done. (Although I do like the case for `iptr` and `uptr`.)

TODO: Add usage examples.
@1fish2

This comment has been minimized.

Show comment
Hide comment
@1fish2

1fish2 Nov 14, 2014

Great points, everyone. This revision gets in most of the feedback.

1fish2 commented Nov 14, 2014

Great points, everyone. This revision gets in most of the feedback.

@Gankro

This comment has been minimized.

Show comment
Hide comment
@Gankro

Gankro Nov 14, 2014

Contributor

I'm another vote for iptr and uptr. Short, simple, clear.

I'd also still be interested in having a uint and int type as synonyms for u32 and i32 for a programmer to signal that the size of integers has not seriously been reflected upon. I get the impression this is what mostly people are using uint and int for outside of their "intended" use. This also matches precisely with when int fallback is expected to kick in: the programmer wanted numbers (possibly just as some vague dummy data), but hasn't clearly reflected on the types of these numbers.

Not sure if this is out of scope for this RFC or not. I'm genuinely a little lost on the full hierarchy/relationship of all these different int RFCs.

Contributor

Gankro commented Nov 14, 2014

I'm another vote for iptr and uptr. Short, simple, clear.

I'd also still be interested in having a uint and int type as synonyms for u32 and i32 for a programmer to signal that the size of integers has not seriously been reflected upon. I get the impression this is what mostly people are using uint and int for outside of their "intended" use. This also matches precisely with when int fallback is expected to kick in: the programmer wanted numbers (possibly just as some vague dummy data), but hasn't clearly reflected on the types of these numbers.

Not sure if this is out of scope for this RFC or not. I'm genuinely a little lost on the full hierarchy/relationship of all these different int RFCs.

@vks

This comment has been minimized.

Show comment
Hide comment
@vks

vks Nov 14, 2014

I'm not convinced having int as a synonym for i32 is the right thing to do. i32 is a more precise name, and does not hide the limited range of numbers it can represent. We can teach Rust programmers in the guide to use i32 as a default.

(I don't think that it is an unimportant detail that can be glossed over, because the programmer should be conscious about the limits of i32. If we defaulted to bigints like for instance Python, we could get away with glossing over the details.)

vks commented Nov 14, 2014

I'm not convinced having int as a synonym for i32 is the right thing to do. i32 is a more precise name, and does not hide the limited range of numbers it can represent. We can teach Rust programmers in the guide to use i32 as a default.

(I don't think that it is an unimportant detail that can be glossed over, because the programmer should be conscious about the limits of i32. If we defaulted to bigints like for instance Python, we could get away with glossing over the details.)

@l0kod

This comment has been minimized.

Show comment
Hide comment
@l0kod

l0kod Nov 14, 2014

I'd also still be interested in having a uint and int type as synonyms for u32 and i32

Agree with @vks, moreover we would miss the opportunity to fix the code currently using int/uint.

Same argument for dropping u and i suffixes (for now).

l0kod commented Nov 14, 2014

I'd also still be interested in having a uint and int type as synonyms for u32 and i32

Agree with @vks, moreover we would miss the opportunity to fix the code currently using int/uint.

Same argument for dropping u and i suffixes (for now).

@arcto

This comment has been minimized.

Show comment
Hide comment
@arcto

arcto Nov 14, 2014

I also agree with @vks on int/uint; the ranges of integer types are too essential to not consider. Please take this opportunity to eliminate a whole bunch of bugs.

I'd also like to give my +1 to either of these alternatives:
iptr, uptr (shorter)
intptr, uintptr (perhaps clearer)

arcto commented Nov 14, 2014

I also agree with @vks on int/uint; the ranges of integer types are too essential to not consider. Please take this opportunity to eliminate a whole bunch of bugs.

I'd also like to give my +1 to either of these alternatives:
iptr, uptr (shorter)
intptr, uintptr (perhaps clearer)

@Kimundi

This comment has been minimized.

Show comment
Hide comment
@Kimundi

Kimundi Nov 21, 2014

Member

Looking at all the suggestion here again, I think I could accept either of iptr/uptr and imem/umem

Member

Kimundi commented Nov 21, 2014

Looking at all the suggestion here again, I think I could accept either of iptr/uptr and imem/umem

@vadimcn

This comment has been minimized.

Show comment
Hide comment
@vadimcn

vadimcn Nov 24, 2014

Contributor

iptr/uptr please

Contributor

vadimcn commented Nov 24, 2014

iptr/uptr please

@1fish2

This comment has been minimized.

Show comment
Hide comment
@1fish2

1fish2 Nov 24, 2014

Is there anyone who prefers the names int and uint for these two machine-dependent integer types with the same width as a target platform pointer?

1fish2 commented Nov 24, 2014

Is there anyone who prefers the names int and uint for these two machine-dependent integer types with the same width as a target platform pointer?

@netvl

This comment has been minimized.

Show comment
Hide comment
@netvl

netvl Nov 25, 2014

@1fish2, yes, I personally think that int/uint are fine, but as far as I can see everyone else think otherwise :)
But, frankly, renaming them does make sense.

netvl commented Nov 25, 2014

@1fish2, yes, I personally think that int/uint are fine, but as far as I can see everyone else think otherwise :)
But, frankly, renaming them does make sense.

@jmesmon

This comment has been minimized.

Show comment
Hide comment
@jmesmon

jmesmon commented Nov 25, 2014

@1fish2 +1

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Nov 26, 2014

Member

(jf we are going to rename, I would prefer imem/umem over iptr/uptr.)

Member

pnkfelix commented Nov 26, 2014

(jf we are going to rename, I would prefer imem/umem over iptr/uptr.)

@nodakai

This comment has been minimized.

Show comment
Hide comment
@nodakai

nodakai Nov 27, 2014

I totally agree with @glaebhoerl in both of these two points:

  1. Banishing int / uint is much more important than choosing specific names (as emphasized by @thestinger , too)
  2. Prefer isize / usize to iptr / uptr because: "What have pointers got to do with it? Is there something unsafe going on?"

nodakai commented Nov 27, 2014

I totally agree with @glaebhoerl in both of these two points:

  1. Banishing int / uint is much more important than choosing specific names (as emphasized by @thestinger , too)
  2. Prefer isize / usize to iptr / uptr because: "What have pointers got to do with it? Is there something unsafe going on?"
@gulbanana

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana Nov 27, 2014

It'd be great to do away with the legacy of 'default ints' as variably sized. Most of the suggested names seem better than the status quo. (I like iptr and uptr personally; the primary argument against this is that it doesn't make sense unless you've learned things, but you have to learn those things to reasonably use rust..)

gulbanana commented Nov 27, 2014

It'd be great to do away with the legacy of 'default ints' as variably sized. Most of the suggested names seem better than the status quo. (I like iptr and uptr personally; the primary argument against this is that it doesn't make sense unless you've learned things, but you have to learn those things to reasonably use rust..)

@barosl

This comment has been minimized.

Show comment
Hide comment
@barosl

barosl Dec 9, 2014

Contributor

It seems that the bikeshedding is stalled, but I hope this would land before 1.0. I try to use i32 wherever possible, but I often carelessly choose int because it is allowed by the language.

Personally I am OK with either umem or uptr. I have a slight preference on umem because it may confuse newcomers less (0um and 0im is prettier than 0up and 0ip, too!), but I also like uptr because it reminds me of uintptr_t in C.

Contributor

barosl commented Dec 9, 2014

It seems that the bikeshedding is stalled, but I hope this would land before 1.0. I try to use i32 wherever possible, but I often carelessly choose int because it is allowed by the language.

Personally I am OK with either umem or uptr. I have a slight preference on umem because it may confuse newcomers less (0um and 0im is prettier than 0up and 0ip, too!), but I also like uptr because it reminds me of uintptr_t in C.

@1fish2

This comment has been minimized.

Show comment
Hide comment
@1fish2

1fish2 Dec 9, 2014

I wrote in the intro:

This RFC assumes a fixed-size integer type will become the type inference fallback and thus the language's "default integer type" and, in turn, heavily used in tutorials and libraries.

but a BigInt type would fill the type inference fallback role at least as well. I should've written "a platform-independent integer type"...

1fish2 commented Dec 9, 2014

I wrote in the intro:

This RFC assumes a fixed-size integer type will become the type inference fallback and thus the language's "default integer type" and, in turn, heavily used in tutorials and libraries.

but a BigInt type would fill the type inference fallback role at least as well. I should've written "a platform-independent integer type"...

@l0kod

This comment has been minimized.

Show comment
Hide comment
@l0kod

l0kod Dec 14, 2014

As Rust will soon reach 1.0 and because of the (invasive) breaking change, this RFC should quickly be accepted, otherwise it will never land.

cc @pnkfelix

l0kod commented Dec 14, 2014

As Rust will soon reach 1.0 and because of the (invasive) breaking change, this RFC should quickly be accepted, otherwise it will never land.

cc @pnkfelix

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Dec 14, 2014

Member

@l0kod the Rust team discussed this at the work week (week before last), there is broad support for a renaming, but discussion about the details is ongoing and theirs still some work to do to find consensus. It's definitely on our minds though!

Member

nrc commented Dec 14, 2014

@l0kod the Rust team discussed this at the work week (week before last), there is broad support for a renaming, but discussion about the details is ongoing and theirs still some work to do to find consensus. It's definitely on our minds though!

@rkjnsn

This comment has been minimized.

Show comment
Hide comment
@rkjnsn

rkjnsn Dec 18, 2014

Contributor

I want to add that I strongly prefer imem/umem over iptr/uptr

Contributor

rkjnsn commented Dec 18, 2014

I want to add that I strongly prefer imem/umem over iptr/uptr

@1fish2

This comment has been minimized.

Show comment
Hide comment
@1fish2

1fish2 Dec 21, 2014

I posted a poll on G+, phrasing it as a time-travelling C change to include programmers unfamiliar with Rust.

Anyway, I agree that the main point is to change the name, and I personally prefer imem & umem.

1fish2 commented Dec 21, 2014

I posted a poll on G+, phrasing it as a time-travelling C change to include programmers unfamiliar with Rust.

Anyway, I agree that the main point is to change the name, and I personally prefer imem & umem.

@vks

This comment has been minimized.

Show comment
Hide comment
@vks

vks Dec 22, 2014

I posted a poll on G+, phrasing it as a time-travelling C change to include programmers unfamiliar with Rust.

Does it tell you how many people voted on it?

vks commented Dec 22, 2014

I posted a poll on G+, phrasing it as a time-travelling C change to include programmers unfamiliar with Rust.

Does it tell you how many people voted on it?

@tbu-

This comment has been minimized.

Show comment
Hide comment
@tbu-

tbu- Dec 22, 2014

Contributor

@vks The vote count is right above the picture for me. Currently 6 people have voted.

Contributor

tbu- commented Dec 22, 2014

@vks The vote count is right above the picture for me. Currently 6 people have voted.

@liigo

This comment has been minimized.

Show comment
Hide comment
@liigo

liigo Dec 22, 2014

Contributor

iptr/uptr looks fine for me. imem/umem doesn't make sense because
everything else are memory too.

Contributor

liigo commented Dec 22, 2014

iptr/uptr looks fine for me. imem/umem doesn't make sense because
everything else are memory too.

@tbu-

This comment has been minimized.

Show comment
Hide comment
@tbu-

tbu- Dec 22, 2014

Contributor

@liigo The reasoning for imem/umem is that it represents a memory address, it's sized so that it can address the whole memory.

Contributor

tbu- commented Dec 22, 2014

@liigo The reasoning for imem/umem is that it represents a memory address, it's sized so that it can address the whole memory.

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Dec 23, 2014

Member

This was discussed a lot by the Rust team and the core team and, eventually, decided against. See this post for more of the reasoning behind the decision

Member

nrc commented Dec 23, 2014

This was discussed a lot by the Rust team and the core team and, eventually, decided against. See this post for more of the reasoning behind the decision

@nrc nrc closed this Dec 23, 2014

@l0kod

This comment has been minimized.

Show comment
Hide comment
@l0kod

l0kod Dec 24, 2014

Despite all the favorable comments about this great RFC, the fear of a new breaking change (even before the 1.0 milestone) was greater... 😞

l0kod commented Dec 24, 2014

Despite all the favorable comments about this great RFC, the fear of a new breaking change (even before the 1.0 milestone) was greater... 😞

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Dec 24, 2014

@l0kod: It's clearly not why because changes like opt-in Copy or most of the other recent breaks were harder to deal with than a guided search / replace. The second stated rationale is the issue of familiarity which is clearing missing the entire point. Familiarity is a bad thing because these types are defined differently in other languages. No one is going to infer that i32 is the type for general purpose usage and int is a pointer-size integer from the names.

The decision was made based on closed-door discussions without people who understood the motives behind the RFC. The public explanation likely has very little to do with the conversions that actually occurred. I don't know why anyone would still expect the core developers to be open and honest.

thestinger commented Dec 24, 2014

@l0kod: It's clearly not why because changes like opt-in Copy or most of the other recent breaks were harder to deal with than a guided search / replace. The second stated rationale is the issue of familiarity which is clearing missing the entire point. Familiarity is a bad thing because these types are defined differently in other languages. No one is going to infer that i32 is the type for general purpose usage and int is a pointer-size integer from the names.

The decision was made based on closed-door discussions without people who understood the motives behind the RFC. The public explanation likely has very little to do with the conversions that actually occurred. I don't know why anyone would still expect the core developers to be open and honest.

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Dec 24, 2014

Contributor

The decision was made based on closed-door discussions without people who understood the motives behind the RFC. The public explanation likely has very little to do with the conversions that actually occurred. I don't know why anyone would still expect the core developers to be open and honest

I'm genuinely unsure what you mean by this. Maybe there's an ultra-secret core group that is making decisions without me and has even more ultra-secret motivations, but at least for me, the stated rationale is the rationale we discussed as a group.

Contributor

wycats commented Dec 24, 2014

The decision was made based on closed-door discussions without people who understood the motives behind the RFC. The public explanation likely has very little to do with the conversions that actually occurred. I don't know why anyone would still expect the core developers to be open and honest

I'm genuinely unsure what you mean by this. Maybe there's an ultra-secret core group that is making decisions without me and has even more ultra-secret motivations, but at least for me, the stated rationale is the rationale we discussed as a group.

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Dec 24, 2014

@wycats: I don't place much weight in the word of someone who makes personal attacks on me in private discussions after putting on a completely different persona in conversions with me. I know for a fact that there's even internal dissent about the way this went down because I was told by at least one person who was there.

thestinger commented Dec 24, 2014

@wycats: I don't place much weight in the word of someone who makes personal attacks on me in private discussions after putting on a completely different persona in conversions with me. I know for a fact that there's even internal dissent about the way this went down because I was told by at least one person who was there.

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Dec 24, 2014

Contributor

@thestinger I'm pretty sure I would tell you (to your face) anything I've said in private to anyone. I think that you are very talented and have many very good insights on issues. I believe that Mozilla has a need to grow the core team so it includes people who are not employees of Mozilla, and I have strongly advocated for that for nearly a year now. I also believe that if you're worried about Mozilla influence, your best bet is on the continued growth of the Rust community, who will naturally dilute the influence that Mozilla has now as one of only a few companies paying multiple people to write Rust code every day.

On the flip side, I feel that you have been both technically sloppy and vitriolic in your comments (this is not a personal attack, just an observation). I feel that the way that you talk about Rust and the core team is actually more likely to leave a trail of damage in your wake than achieve your goals of more diversified decisionmaking. In private, I have absolutely vented about the frustrating way you have chosen to engage with the community.

The frustrating thing for me is that I have largely agreed historically with many of your technical critiques and your organizational critiques, but I've watched the core team (both before and after I joined) take your concerns extremely seriously. They haven't always agreed with you at the end of the day, but they have spent countless hours seriously engaging with every technical critique you've raised, and have often come to agree with you.

In response, you have ratcheted up the level of vitriol and conspiracy theorizing, and have repeatedly and publicly threatened to fork Rust. I'll ask you again what I asked you in private: if you're interested in the success of Rust, please try to work as a collaborator, rather than as an enemy. I would welcome collaboration with both arms.

Contributor

wycats commented Dec 24, 2014

@thestinger I'm pretty sure I would tell you (to your face) anything I've said in private to anyone. I think that you are very talented and have many very good insights on issues. I believe that Mozilla has a need to grow the core team so it includes people who are not employees of Mozilla, and I have strongly advocated for that for nearly a year now. I also believe that if you're worried about Mozilla influence, your best bet is on the continued growth of the Rust community, who will naturally dilute the influence that Mozilla has now as one of only a few companies paying multiple people to write Rust code every day.

On the flip side, I feel that you have been both technically sloppy and vitriolic in your comments (this is not a personal attack, just an observation). I feel that the way that you talk about Rust and the core team is actually more likely to leave a trail of damage in your wake than achieve your goals of more diversified decisionmaking. In private, I have absolutely vented about the frustrating way you have chosen to engage with the community.

The frustrating thing for me is that I have largely agreed historically with many of your technical critiques and your organizational critiques, but I've watched the core team (both before and after I joined) take your concerns extremely seriously. They haven't always agreed with you at the end of the day, but they have spent countless hours seriously engaging with every technical critique you've raised, and have often come to agree with you.

In response, you have ratcheted up the level of vitriol and conspiracy theorizing, and have repeatedly and publicly threatened to fork Rust. I'll ask you again what I asked you in private: if you're interested in the success of Rust, please try to work as a collaborator, rather than as an enemy. I would welcome collaboration with both arms.

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Dec 24, 2014

I'm pretty sure I would tell you (to your face) anything I've said in private to anyone.

That's clearly not true, as you pointed out yourself later in this comment.

I believe that Mozilla has a need to grow the core team so it includes people who are not employees of Mozilla, and I have strongly advocated for that for nearly a year now.

Including contractors instead of just normal employees isn't much of a change.

I also believe that if you're worried about Mozilla influence, your best bet is on the continued growth of the Rust community, who will naturally dilute the influence that Mozilla has now as one of only a few companies paying multiple people to write Rust code every day.

The problem isn't the influence of Mozilla. It's the fact that there's so much influence by people with no respect for the community or the project. It's a problem with people who are unable to approach technical issues without their personal bias / feuds getting in the way and who resort to dishonest, manipulative tactics to push their point of view. Mozilla's involvement just guarantees that these will continue to be the people in charge.

On the flip side, I feel that you have been both technically sloppy and vitriolic in your comments (this is not a personal attack, just an observation).

This is just laughable bullshit. The only time I'm vitriolic is in response to two-faced liars like yourself. I think FUD deserves to be called out, as does nasty political nonsense like like certain people who felt it necessary to block my pull requests with whatever pile of bullshit reasons they could pull out of their ass.

You calling my contributions technically sloppy is just a projection of your own incompetence. You don't have any real arguments to make so you're just going to totally misrepresent the facts. That's the usual pattern that I've grown to expect.

I feel that the way that you talk about Rust and the core team is actually more likely to leave a trail of damage in your wake than achieve your goals of more diversified decisionmaking.

I suggest cutting down on the FUD and manipulative tactics if you don't want to be called out on it.

In private, I have absolutely vented about the frustrating way you have chosen to engage with the community.

I've only "chosen to engage" like this with a select few people on the core team. People who habitually resort to lying / manipulation / politics have no place managing a community like this.

The frustrating thing for me is that I have largely agreed historically with many of your technical critiques and your organizational critiques, but I've watched the core team (both before and after I joined) take your concerns extremely seriously.

They haven't always agreed with you at the end of the day, but they have spent countless hours seriously engaging with every technical critique you've raised, and have often come to agree with you.

This isn't about technical issues. The problem is a lack of openness, manipulation, lying, taking credit for other people's ideas / work, putting procedure above common sense and letting personal politics drive decision making / actions rather than the good of the project.

In response, you have ratcheted up the level of vitriol and conspiracy theorizing, and have repeatedly and publicly threatened to fork Rust.

Once again, you're using manipulative language like "conspiracy theorizing" to white-wash real cases where the community has be abused. You're the one ratcheting up the vitriol by misrepresenting everything and resorting to so much passive aggression.

I'll ask you again what I asked you in private: if you're interested in the success of Rust, please try to work as a collaborator, rather than as an enemy. At least I would welcome collaboration with both arms.

I have no interest in collaborating with pathological liars. You said a lot of things to me in private that I've had to re-evaluate after finding out it was just a show.

thestinger commented Dec 24, 2014

I'm pretty sure I would tell you (to your face) anything I've said in private to anyone.

That's clearly not true, as you pointed out yourself later in this comment.

I believe that Mozilla has a need to grow the core team so it includes people who are not employees of Mozilla, and I have strongly advocated for that for nearly a year now.

Including contractors instead of just normal employees isn't much of a change.

I also believe that if you're worried about Mozilla influence, your best bet is on the continued growth of the Rust community, who will naturally dilute the influence that Mozilla has now as one of only a few companies paying multiple people to write Rust code every day.

The problem isn't the influence of Mozilla. It's the fact that there's so much influence by people with no respect for the community or the project. It's a problem with people who are unable to approach technical issues without their personal bias / feuds getting in the way and who resort to dishonest, manipulative tactics to push their point of view. Mozilla's involvement just guarantees that these will continue to be the people in charge.

On the flip side, I feel that you have been both technically sloppy and vitriolic in your comments (this is not a personal attack, just an observation).

This is just laughable bullshit. The only time I'm vitriolic is in response to two-faced liars like yourself. I think FUD deserves to be called out, as does nasty political nonsense like like certain people who felt it necessary to block my pull requests with whatever pile of bullshit reasons they could pull out of their ass.

You calling my contributions technically sloppy is just a projection of your own incompetence. You don't have any real arguments to make so you're just going to totally misrepresent the facts. That's the usual pattern that I've grown to expect.

I feel that the way that you talk about Rust and the core team is actually more likely to leave a trail of damage in your wake than achieve your goals of more diversified decisionmaking.

I suggest cutting down on the FUD and manipulative tactics if you don't want to be called out on it.

In private, I have absolutely vented about the frustrating way you have chosen to engage with the community.

I've only "chosen to engage" like this with a select few people on the core team. People who habitually resort to lying / manipulation / politics have no place managing a community like this.

The frustrating thing for me is that I have largely agreed historically with many of your technical critiques and your organizational critiques, but I've watched the core team (both before and after I joined) take your concerns extremely seriously.

They haven't always agreed with you at the end of the day, but they have spent countless hours seriously engaging with every technical critique you've raised, and have often come to agree with you.

This isn't about technical issues. The problem is a lack of openness, manipulation, lying, taking credit for other people's ideas / work, putting procedure above common sense and letting personal politics drive decision making / actions rather than the good of the project.

In response, you have ratcheted up the level of vitriol and conspiracy theorizing, and have repeatedly and publicly threatened to fork Rust.

Once again, you're using manipulative language like "conspiracy theorizing" to white-wash real cases where the community has be abused. You're the one ratcheting up the vitriol by misrepresenting everything and resorting to so much passive aggression.

I'll ask you again what I asked you in private: if you're interested in the success of Rust, please try to work as a collaborator, rather than as an enemy. At least I would welcome collaboration with both arms.

I have no interest in collaborating with pathological liars. You said a lot of things to me in private that I've had to re-evaluate after finding out it was just a show.

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Dec 24, 2014

Happy holidays everyone!

stefanpenner commented Dec 24, 2014

Happy holidays everyone!

@franontanaya

This comment has been minimized.

Show comment
Hide comment
@franontanaya

franontanaya Dec 29, 2014

i0 as opposed to i32 and i64 would look to me like a not fixed size.

franontanaya commented Dec 29, 2014

i0 as opposed to i32 and i64 would look to me like a not fixed size.

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Dec 29, 2014

@franontanaya: A pointer-size integer is not the only useful architecture-specific integer type.

thestinger commented Dec 29, 2014

@franontanaya: A pointer-size integer is not the only useful architecture-specific integer type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment