Repository navigation
[BUG] pointer in class can be set to nullptr in constructor but cannot be initialised inline #280
Description
Activity
Does https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r3-a-raw-pointer-a-t-is-non-owning applies to cppfront?
In Cpp2, raw pointers are expected to be non-owning pointers to a single object.
The disallowing of nulls is its own experiment, and the checks for that are known to be partial and mainly just enough to start getting a feel for what that path is like. I don't know yet whether disallowing nulls is going to work out or not, particularly since nulls will still come from Cpp1 types and functions, so I think what's there is probably roughed-in enough for now (even if it's a bit inconsistent about what it does and doesn't diagnose, as above). If as we get further along we like this path, then we can do a more complete job of disallowing nulls.
Reacted by Filip SajdakI think Herb can take a look at null handling in kotlin as it tackles a similar problem to cpp2. Kotlin interops with Java and therefore has null pointers coming from Java. Null pointers are not allowed by default in kotlin but there are various operators to enable and handle null pointers.
A link to documentation@AbhinavK00 regarding the use of ? We have some discussion here: #106 (comment)
We end up not introducing it but the use case was different.
I think it was discussed in context of returning errors (from casts).
This is a different use case like you pointed out, so a discussion is worth it I guess.Also, regarding error handling, Herb gave a cppcon talk in 2018/2019(?, don't remember clearly) but I'm curious if that's how Herb plans to implement error handling in cpp2 because it's not mentioned in road map.
(I gotta rewatch the talk because I can't remember it, but it was lightweight exceptions ig)Edit sorry I missed something 😅. This was my in mind when I was thinking of roadmap.
It's in the first sentence of the README.
This compiler is a work in progress and currently hilariously incomplete... basic functions work, classes will be next, then metaclasses and lightweight exceptions.
The current implementation of cppfront (4c52d2d) for the following code:
node: type = { parent: *node; operator=: (out this) = { parent = nullptr; } }Generates (skipping boilerplate):
When I tried to initialize parent in place:
node: type = { parent: *node = nullptr; operator=: (out this) = { } }I got an error:
Expectations
I expect to have consistent behavior here. Both ways should end up with the same results.
Question
How will we model structures that use nullptrs as terminators? In the given scenario, parent is a non-owning pointer that can be null.