some stylistic improvements to toTypeFunction()#7754
Conversation
|
Thanks for your pull request, @WalterBright! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. |
| return cast(TypeFunction)t.nextOf(); | ||
| else if (t.ty == Type.Kind.pointer && t.nextOf().ty == Type.Kind.function_) | ||
| tf = cast(TypeFunction)t.nextOf(); | ||
| return cast(TypeFunction)t.nextOf(); |
There was a problem hiding this comment.
two redundant elses, but I'll let them be
There was a problem hiding this comment.
You're right, I missed that.
|
@WalterBright, I'm sorry if you felt this was merged prematurely. But please note that the PR is actually almost 9 months old, and I assumed you were OK with it due to this comment from you in the original PR.
|
|
I reserve the right to learn how to do things better over time :-) |
|
The comment was written a way I would write code: with indentation. I don't mind the change too much. However after your changes toTypeFunction will be unable to go through the inliner; which I also considered when writing it. Using multiple returns bloats the code. I do understand that one might not value performance for trait evaluation, but that's no reason to actively degrade it. |
5 participants
#7749 got merged before I reviewed it, so my review is coming in the form of a touch-up PR.
Please don't invent a new formatting style for function Ddoc comments.
I find default arguments make code harder to understand. Besides, this is an almost ideal use case for an
outparameter.outparameters eliminate the null pointer issue, are more checkably memory safe, and the code is simpler.Reorganized the code a bit to eliminate variable
tfand reduce the scope ofs.cc @UplinkCoder @JinShil