Swift class, method and property restrictions











up vote
1
down vote

favorite












I'm searching for a working compromise between readability / usability and performance improvements through code restrictions.



According to this question and the linked Apple document it seems to be very important to use code restrictions as often as possible.



On the other hand, I have never seen an example where all code restrictions are implemented and I would never try to code like this:



    final internal class TestClass {
final private var result: String = "Result"
...

final internal func TestMethod(result: String) -> String {
...
}
}


So is there a generally accepted and "working" compromise?



EDIT



In other words, if the performance improvement generated by code restrictions like final and private is as huge as mentioned in the attached article, why do we see it very rarely? And why isn't it the default behavior?










share|improve this question




















  • 1




    It's unclear what you are asking. Please edit your question (no comments) clarifying your question. What problem are you having exactly?
    – rmaddy
    Nov 11 at 19:27










  • @rmaddy hope this edit help to understand me :)
    – Passe
    Nov 11 at 22:06















up vote
1
down vote

favorite












I'm searching for a working compromise between readability / usability and performance improvements through code restrictions.



According to this question and the linked Apple document it seems to be very important to use code restrictions as often as possible.



On the other hand, I have never seen an example where all code restrictions are implemented and I would never try to code like this:



    final internal class TestClass {
final private var result: String = "Result"
...

final internal func TestMethod(result: String) -> String {
...
}
}


So is there a generally accepted and "working" compromise?



EDIT



In other words, if the performance improvement generated by code restrictions like final and private is as huge as mentioned in the attached article, why do we see it very rarely? And why isn't it the default behavior?










share|improve this question




















  • 1




    It's unclear what you are asking. Please edit your question (no comments) clarifying your question. What problem are you having exactly?
    – rmaddy
    Nov 11 at 19:27










  • @rmaddy hope this edit help to understand me :)
    – Passe
    Nov 11 at 22:06













up vote
1
down vote

favorite









up vote
1
down vote

favorite











I'm searching for a working compromise between readability / usability and performance improvements through code restrictions.



According to this question and the linked Apple document it seems to be very important to use code restrictions as often as possible.



On the other hand, I have never seen an example where all code restrictions are implemented and I would never try to code like this:



    final internal class TestClass {
final private var result: String = "Result"
...

final internal func TestMethod(result: String) -> String {
...
}
}


So is there a generally accepted and "working" compromise?



EDIT



In other words, if the performance improvement generated by code restrictions like final and private is as huge as mentioned in the attached article, why do we see it very rarely? And why isn't it the default behavior?










share|improve this question















I'm searching for a working compromise between readability / usability and performance improvements through code restrictions.



According to this question and the linked Apple document it seems to be very important to use code restrictions as often as possible.



On the other hand, I have never seen an example where all code restrictions are implemented and I would never try to code like this:



    final internal class TestClass {
final private var result: String = "Result"
...

final internal func TestMethod(result: String) -> String {
...
}
}


So is there a generally accepted and "working" compromise?



EDIT



In other words, if the performance improvement generated by code restrictions like final and private is as huge as mentioned in the attached article, why do we see it very rarely? And why isn't it the default behavior?







swift restriction






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 11 at 22:05

























asked Nov 11 at 19:22









Passe

307319




307319








  • 1




    It's unclear what you are asking. Please edit your question (no comments) clarifying your question. What problem are you having exactly?
    – rmaddy
    Nov 11 at 19:27










  • @rmaddy hope this edit help to understand me :)
    – Passe
    Nov 11 at 22:06














  • 1




    It's unclear what you are asking. Please edit your question (no comments) clarifying your question. What problem are you having exactly?
    – rmaddy
    Nov 11 at 19:27










  • @rmaddy hope this edit help to understand me :)
    – Passe
    Nov 11 at 22:06








1




1




It's unclear what you are asking. Please edit your question (no comments) clarifying your question. What problem are you having exactly?
– rmaddy
Nov 11 at 19:27




It's unclear what you are asking. Please edit your question (no comments) clarifying your question. What problem are you having exactly?
– rmaddy
Nov 11 at 19:27












@rmaddy hope this edit help to understand me :)
– Passe
Nov 11 at 22:06




@rmaddy hope this edit help to understand me :)
– Passe
Nov 11 at 22:06












1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted










The linked answer mis-states the linked blog post. If you're using Whole Module Optimization (which you should always be using in Release mode), you generally do not need to proactively add final or private for performance reasons. The compiler will figure out when they can be inserted. You should use final and private to express your intent to other programmers (and yourself), not the optimizer.




However, if Whole Module Optimization is enabled, all of the module is compiled together at the same time. This allows the compiler to make inferences about the entire module together and infer final on declarations with internal if there are no visible overrides.







share|improve this answer























  • Got it, thanks!
    – Passe
    Nov 12 at 5:55











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53252324%2fswift-class-method-and-property-restrictions%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted










The linked answer mis-states the linked blog post. If you're using Whole Module Optimization (which you should always be using in Release mode), you generally do not need to proactively add final or private for performance reasons. The compiler will figure out when they can be inserted. You should use final and private to express your intent to other programmers (and yourself), not the optimizer.




However, if Whole Module Optimization is enabled, all of the module is compiled together at the same time. This allows the compiler to make inferences about the entire module together and infer final on declarations with internal if there are no visible overrides.







share|improve this answer























  • Got it, thanks!
    – Passe
    Nov 12 at 5:55















up vote
1
down vote



accepted










The linked answer mis-states the linked blog post. If you're using Whole Module Optimization (which you should always be using in Release mode), you generally do not need to proactively add final or private for performance reasons. The compiler will figure out when they can be inserted. You should use final and private to express your intent to other programmers (and yourself), not the optimizer.




However, if Whole Module Optimization is enabled, all of the module is compiled together at the same time. This allows the compiler to make inferences about the entire module together and infer final on declarations with internal if there are no visible overrides.







share|improve this answer























  • Got it, thanks!
    – Passe
    Nov 12 at 5:55













up vote
1
down vote



accepted







up vote
1
down vote



accepted






The linked answer mis-states the linked blog post. If you're using Whole Module Optimization (which you should always be using in Release mode), you generally do not need to proactively add final or private for performance reasons. The compiler will figure out when they can be inserted. You should use final and private to express your intent to other programmers (and yourself), not the optimizer.




However, if Whole Module Optimization is enabled, all of the module is compiled together at the same time. This allows the compiler to make inferences about the entire module together and infer final on declarations with internal if there are no visible overrides.







share|improve this answer














The linked answer mis-states the linked blog post. If you're using Whole Module Optimization (which you should always be using in Release mode), you generally do not need to proactively add final or private for performance reasons. The compiler will figure out when they can be inserted. You should use final and private to express your intent to other programmers (and yourself), not the optimizer.




However, if Whole Module Optimization is enabled, all of the module is compiled together at the same time. This allows the compiler to make inferences about the entire module together and infer final on declarations with internal if there are no visible overrides.








share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 12 at 1:42

























answered Nov 12 at 1:36









Rob Napier

197k28290416




197k28290416












  • Got it, thanks!
    – Passe
    Nov 12 at 5:55


















  • Got it, thanks!
    – Passe
    Nov 12 at 5:55
















Got it, thanks!
– Passe
Nov 12 at 5:55




Got it, thanks!
– Passe
Nov 12 at 5:55


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53252324%2fswift-class-method-and-property-restrictions%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Bressuire

Vorschmack

Quarantine