Skip to content
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

Replace let/nil-check patterns with guard let #157

Closed
wants to merge 10 commits into from

Conversation

dbworku
Copy link

@dbworku dbworku commented Dec 4, 2015

The let/nil-check pattern is more expensive and less elegant than
guard let.

  • The elegance goes without reasoning.
  • I confirmed, after some experiments with the Swift complier, that it guard let is also less expensive.

The change on LazyMapGenerator should increase performance negligibly of map().

The let/nil-check pattern is more expensive and less elegant than
`guard let`.
subscriptBaseAddress: UnsafeMutablePointer(cocoaStorageBaseAddress),
indices: subRange,
hasNativeBuffer: false)
guard let cocoaStorageBaseAddress = cocoa.contiguousStorage(self.indices) else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer this the old way. guard is supposed to be a quick-exit path, and in this case, if plays that role well.

@gribozavr
Copy link
Contributor

Please update the pull request based on the comments.

Did you run the tests? build-script -RT

@dbworku
Copy link
Author

dbworku commented Dec 4, 2015

@gribozavr @radex Thanks for the comments!

I will replace branches with non-trivial amount of code on either side with the if let pattern.

@dbworku
Copy link
Author

dbworku commented Dec 4, 2015

@gribozavr I couldn't test this PR because build-script -RT went down went linking the build files.

[475/1921] Linking CXX shared module lib/LLVMHello.dylib
FAILED: : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++  -fno-stack-protector -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -std=c++11 -fcolor-diagnostics -O3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.9 -bundle -Wl,-headerpad_max_install_names -Wl,-flat_namespace -Wl,-undefined -Wl,suppress   -Wl,-dead_strip -Wl,-exported_symbols_list,/Users/Daniel/Documents/Apple Projects/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/lib/Transforms/Hello/LLVMHello.exports -o lib/LLVMHello.dylib lib/Transforms/Hello/CMakeFiles/LLVMHello.dir/Hello.cpp.o  -Wl,-rpath,@executable_path/../lib && :
clang: error: no such file or directory: 'Projects/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/lib/Transforms/Hello/LLVMHello.exports'
[475/1921] Building CXX object lib/IR/CMakeFiles/LLVMCore.dir/Function.cpp.o
ninja: build stopped: subcommand failed.

@gribozavr
Copy link
Contributor

@dbworku Are you running the latest Xcode beta?

I have never seen this issue, but it is a possibility that there is a missing dependency in LLVM's CMake scripts. Could you run build-script -RT again? If that does not help, could you delete the directory build/Ninja-ReleaseAssert/llvm-macosx-x86_64 and try again?

@nadavrot
Copy link
Contributor

nadavrot commented Dec 4, 2015

@gribozavr @dbworku Please do not commit changes to Array before running the performance test suite. Array is special and regressing the performance of array to improve readability is not okay.

The cmark_node struct and the node.h header are private.
@aschwaighofer
Copy link
Contributor

@gribozavr @nadavrot @dbworku These changes don't look like they should affect performance. I am fine with this going in after @gribozavr gives his okay.

@gribozavr
Copy link
Contributor

@aschwaighofer Thank you for reviewing!

I'm OK with the parts that I marked as LGTM in other comments.

cwillmor and others added 7 commits December 4, 2015 18:19
I filed this under Radar rather than bugs.swift.org because it's /only/ our
CI system that's failing, and external contributors have no insight into
that anyway. Hopefully I'll be able to get to the bottom of this soon.
This is needed for Xcode support, even though it appeared dead within the Swift repo itself.
The let/nil-check pattern is more expensive and less elegant than
`guard let`.
@dbworku
Copy link
Author

dbworku commented Dec 5, 2015

@gribozavr Deleting/Reinstalling both Xcode's (release and beta) fixed my build issues.

I mangled this branch's history when rebasing after the PR #193 changes. Closing this PR in favor of a single commit that includes all of the requested changes.

@dbworku dbworku closed this Dec 5, 2015
@dbworku dbworku deleted the Guard-Let branch December 5, 2015 15:27
dabelknap pushed a commit to dabelknap/swift that referenced this pull request Nov 30, 2018
maldahleh pushed a commit to maldahleh/swift that referenced this pull request Oct 26, 2020
freak4pc pushed a commit to freak4pc/swift that referenced this pull request Sep 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.