I've noticed a mix of pointers (FuncDecl*) and references (TypeChecker&) in
the C++ codebase. Is there a particular reason for this? Perhaps a style
guide?
Jacob
In general, we have not been particularly disciplined in this regard. I would suggest following what is being done locally in the file you are modifying, i.e. FuncDecl */TypeChecker & as per the LLVM style guide.
Michael
···
On Dec 12, 2015, at 3:15 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org> wrote:
I've noticed a mix of pointers (FuncDecl*) and references (TypeChecker&) in the C++ codebase. Is there a particular reason for this? Perhaps a style guide?
Jacob
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
In general, we have not been particularly disciplined in this regard. I would suggest following what is being done locally in the file you are modifying, i.e. FuncDecl */TypeChecker & as per the LLVM style guide.
There are common rules at work here that govern most situations. We almost always pass around objects that are part of the language representation as either pointers (e.g. AST/SIL/LLVM nodes) or values (e.g. Type, SILDeclRef); pretty much everything else is passed around as a reference, especially classes that manage the creation or manipulation of the language representation (e.g. IRGenModule, TypeChecker).
The biggest grey area is for those parts of the language representation that are either globally or contextually singleton, e.g. ASTContext and SILFunction; these are almost always stored as references.
John.
···
On Dec 12, 2015, at 4:20 PM, Michael Gottesman via swift-dev <swift-dev@swift.org> wrote:
Michael
On Dec 12, 2015, at 3:15 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
I've noticed a mix of pointers (FuncDecl*) and references (TypeChecker&) in the C++ codebase. Is there a particular reason for this? Perhaps a style guide?
Jacob
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
I was thinking it might help some of the null-dereference issues if more
things were to be passed as references. Is there a particular reason to use
pointers instead? It seems there are several places which accept pointers
and assume they're not null, which isn't really safe.
(And, there's probably some work to be done adding `const` in a bunch of
places.)
Jacob
···
On Mon, Dec 14, 2015 at 11:34 AM, John McCall <rjmccall@apple.com> wrote:
On Dec 12, 2015, at 4:20 PM, Michael Gottesman via swift-dev < > swift-dev@swift.org> wrote:
In general, we have not been particularly disciplined in this regard. I
would suggest following what is being done locally in the file you are
modifying, i.e. FuncDecl */TypeChecker & as per the LLVM style guide.There are common rules at work here that govern most situations. We
almost always pass around objects that are part of the language
representation as either pointers (e.g. AST/SIL/LLVM nodes) or values (e.g.
Type, SILDeclRef); pretty much everything else is passed around as a
reference, especially classes that manage the creation or manipulation of
the language representation (e.g. IRGenModule, TypeChecker).The biggest grey area is for those parts of the language representation
that are either globally or contextually singleton, e.g. ASTContext and
SILFunction; these are almost always stored as references.John.
Michael
On Dec 12, 2015, at 3:15 PM, Jacob Bandes-Storch via swift-dev < > swift-dev@swift.org> wrote:
I've noticed a mix of pointers (FuncDecl*) and references (TypeChecker&)
in the C++ codebase. Is there a particular reason for this? Perhaps a style
guide?Jacob
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
I was thinking it might help some of the null-dereference issues if more things were to be passed as references. Is there a particular reason to use pointers instead? It seems there are several places which accept pointers and assume they're not null, which isn't really safe.
In principle, I agree, hence the design of Swift optionals. However, C++ isn’t very cooperative here. Compilers do a lot of dynamic casting, and to work idiomatically, the result of a dynamic cast needs to be something you can test in an if condition (an optional type, if you will). However, C++ if conditions aren't "test-and-unwrap” like Swift’s if-let, they’re just “test”, so even within the guarded block you now need a lot of fussy (and only contextual safe) code to get back to a non-optional type that you can actually do something with. It’s not really worth it.
(And, there's probably some work to be done adding `const` in a bunch of places.)
My experience is that ‘const’ doesn’t provide much value with language representations. There’s a lot of boilerplate and redundancy to overload operations to propagate const-ness around correctly, you inevitably end up const_cast’ing stuff all the time regardless, and it’s generally well-known whether a particular context has any business modifying the representation (usually: no).
John.
···
On Dec 14, 2015, at 11:43 AM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote: