-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Please consider changing ->
to .
for pointer access
#1725
Comments
Both Rust and D allow name bindings in the smart pointer object to shadow names in the pointed-to-object. Please don't replicate this mistake. |
This probably varies a lot by keyboard layout, but perhaps you could configure yours? Or perhaps do so on the editor level? |
For my UK layout the key presses compare press "." with: press minus, hold shift, press ".", release shift |
While so far I haven't dived deep into Carbon's pointer system my main concern with this suggestion would be ODR. If
But if you ask me the C++ way is just better, no need to worry about definition collisions. |
If we need to distinguish, then we need some syntax to do this, but this would only be a rare case.
This would only apply to methods which collide. I would rather write a bit more verbose and explicit code in some edge cases, than sacrifice general ease of reading/writing code. I work on a code base that uses intrusive pointers and therefore all types which want to be smart'pointed to, would already need to comply to certain rules imposed by the smart pointer, so we would not have any collision at all. |
vs
Using '::' would create confusion for anyone who uses C++, but this is Carbon so we shouldn't care. But what we do care about is interloopability as mentioned in the Cpp North talk, using similar grammar makes that goal more achievable. |
10000 times: s.empty(); |
Thank you for all the discussion. Just to clarify, as stated in the original post, I do not see any need to remove Unless Carbon provides the ability to overload (With that said, above is just my best case compromise in hopes of allowing this feature to exist. Personally I agree with @sor, and if I were in complete control of Carbon, I would purge |
I have to wonder if it actually will be? Part of the brilliance of Rust's optional is you're forced to "extract" the value by using
With that said, even if Carbon's optionals did work like this, Carbon's
|
Please also have a look at this related proposal from @OlaFosheimGrostad : #1736 |
I think this is an interesting and important question, but I want to call out one aspect of how the discussion is happening just so we can keep things focused and productive:
I think it will help to find ways to talk about the specific advantages and drawbacks of the options here. I don't think calling a syntax "archaic" helps much -- it seems hard to draw any specific conclusions, and also seems likely to not be the most friendly description for folks actively using (and maybe enjoying!) C++ and C even today. Anyways, focusing on the specific proposal, this is essentially the same model suggested in other contexts as "implicit dereferencing" of pointers. I do think it is a reasonable model to consider. There is a major drawback of the model that I don't think you're really addressing: it makes it very difficult to differentially refer to methods on the pointer vs. the pointee. In C++, this only really impacts smart pointers as normal pointers have no methods. However, in Carbon we want APIs to be provided by the library which means we will want even raw pointers to have methods. I think an important simplification of the language with pointers vs. references is that it is very unambiguous when referring to the pointer vs. the pointee, and it seems likely to be even more impactful in Carbon. Modeling this as implicit dereferencing leaves open some options for referring to the pointer distinctly from the pointee, but the models tend to be fairly complex, especially in a generic context. Does it apply only when using It also may hide the depth of dereference from the reader. For example, Note that there is an alternative strategy to arrive at |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Putting an idea (not necessarily a good one) out there... we could possibly have our cake (distinguish between The official Carbon spellings of C++'s |
This does still have the problem that |
True, although that's not entirely a new problem: adding methods to a base type can already break subtypes. Carbon culture will also presumably Live at Head and endorse Large Scale Changes. |
Yes, but you can avoid that problem by disallowing inheritance from your type. This problem would unavoidably affect all types.
Yes, but that doesn't mean that breaking charges will have zero cost, it just means they won't have infinite cost. |
This comment was marked as outdated.
This comment was marked as outdated.
Marking this long term since I'm not sure leads will have a quick answer here. |
Long story short,
->
is one of the most miserable operators to type out. I have tried desperately to use alternatives to C++ simply on the basis of not wanting to type this operator thousands of times. As the C++ successor, I'm really hoping Carbon can at least address this problem early-on prior to becoming a major standard that would break all code if changed in the future.While this may seem arbitrary, as I haven't seen this addressed anywhere else in Carbo discussions so far, it does have heavy precedent in modern systems-level languages. Especially Rust, which Carbon appears to be heavily inspired by:
.
for access..
exclusively while retaining a very similar syntax for derefering and pointer types..
operator..
when dealing with it's reference features (out
,in
,ref
).The point I'm trying to make is that
->
is pretty archaic. It would be one thing if Carbon treated pointers "unsafely" like C (I like to think of->
as a C/C++ safety measure to remind yourself you're working with a nullable type), but with Carbon's lack of pointer arithmetic and pointer nullability, its pointers are much more like modern references from the languages described above.In fact, Carbon pointers are more like C++ references, which... yup, also opted to use
.
operator. Hell, aren't C++ "references vs pointers" not the perfect example of C++'s horrible obsession with retaining compatibility as described in Chandler Carruth's talk? Carbon's pointers take all the brilliance of C++'s references, EXCEPT for the syntax part. Why should Carbon inherit such a weird "core" syntax when all modern languages, including C++ from over two decades ago, have provided a better alternative?Now there would be a drawback to removing
->
completely from the language because it would hurt interoperability with C++. While uncommon, there are C++ classes that require using overloaded->
. But, that has nothing to do with how pointer syntax in Carbon should work. You could keep the->
operator as an overload-able option, but make it so the.
operator on pointers default to pointer access on pointers.Hell, if you had a pointer to a class instance that overloaded
->
, you could use->
on that pointer to run that overload, creating a very consistent standard in the language where.
ALWAYS accesses the fields and->
is ALWAYS for special circumstances. I know I'm not the only one who's worked with C++ iterators or third-party code and had to sit back and think about whether I want.
or->
.I'm sure an argument could be made that replacing
.
with->
should be just something I configure in an IDE, and god knows it's one of my favorite reasons to use Qt Creator, but there's still places where I want to refactor code and change a type from pointer to value or vise versa, and it just becomes hell to replace the line of property assignments I do in a constructor/throughout the file. (Or times when the IDE just straight-up lags and I just end up typing arrows explicitly anyway). I would argue with Carbon pointers being so much similar to C++ references and Carbon values, this type of refactoring will be significantly more frequent.I'm crazily in love with Carbon, and I love how so much of the design borrows from modern systems-level languages. So I hope it can become inspired just a little more to make pointers just a bit nicer. Thanks for reading.
The text was updated successfully, but these errors were encountered: