Styjun

Drawing probabilities on a simplex in TikZ

Why might one *not* want to use a capo?

Employing a contractor proving difficult

How to prevent a hosting company from accessing a VM's encryption keys?

What should be done with the carbon when using magic to get oxygen from carbon dioxide?

Why does Sauron not permit his followers to use his name?

Is the Amazon rainforest the "world's lungs"?

Can I lend a small amount of my own money to a bank at the federal funds rate?

Why is the Grievance Studies affair considered to be research requiring IRB approval?

Why is 3/4 a simple meter while 6/8 is a compound meter?

Stolen MacBook should I worry about my data?

Is there an in-universe explanation given to the senior Imperial Navy Officers as to why Darth Vader serves Emperor Palpatine?

Number of Fingers for a Math Oriented Race

Why does AM radio react to IR remote?

Why can't you say don't instead of won't?

Notice period 60 days but I need to join in 45 days

How could a self contained organic body propel itself in space

Which polygons can be turned inside out by a smooth deformation?

Why does the weaker C–H bond have a higher wavenumber than the C=O bond?

Do multi-engine jets need all engines with equal age to reduce asymmetry in thrust and fuel consumption arising out of deterioration?

Looking for a plural noun related to ‘fulcrum’ or ‘pivot’ that denotes multiple things as crucial to success

What is Soda Fountain Etiquette?

Can I get a PhD for developing educational software?

web scraping images

Defer statement at the end of deinit produces a warning

Deinit never calledSwift Method: deinit is not invokeddeinit in empty swift Project not calledSwift's deinit is not calledUIButton deinit not being calledDeinit called twicedeinit is not called in swiftInvoke code in extension on object deinit?Why is deinit not called on UITabBarController?Can I use didSet in deinit?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;

2

Since the Xcode 10.2 (Swift 5) the defer statement at the end of the deinit scope produces:

'defer' statement before end of scope always executes immediately; replace with 'do' statement to silence this warning

Let's take a look at this example:

var foo: String 
 didSet 
 // smt
 


deinit 
 defer <--- Warning
 foo = bar
 

• Of course it's possible to get rid of this warning by moving the code from the observer to a method and call it explicitly but…

What's the point of this warning? - Isn't it reasonable to have the defer statement in the deinit? (e.g. to be able to trigger properties' observers).

swift deinit property-observer

share|improve this question

asked Mar 27 at 21:12

Jakub TruhlářJakub Truhlář

8,84533 gold badges5151 silver badges6262 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  What happens if you do what the warning suggest and replace defer with do ?
  
  – David Rönnqvist
  Mar 27 at 21:27
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  What happens if you place foo = bar at the end of the deinit without defer?
  
  – Ron
  Mar 27 at 21:40
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  In both cases the observer of the property would not be executed. Suggested do itself would be redundant and observers don't run in the init and deinit.
  
  – Jakub Truhlář
  Mar 27 at 22:31
  

  
  
  
  

add a comment | 

2

Since the Xcode 10.2 (Swift 5) the defer statement at the end of the deinit scope produces:

'defer' statement before end of scope always executes immediately; replace with 'do' statement to silence this warning

Let's take a look at this example:

var foo: String 
 didSet 
 // smt
 


deinit 
 defer <--- Warning
 foo = bar
 

• Of course it's possible to get rid of this warning by moving the code from the observer to a method and call it explicitly but…

What's the point of this warning? - Isn't it reasonable to have the defer statement in the deinit? (e.g. to be able to trigger properties' observers).

swift deinit property-observer

share|improve this question

asked Mar 27 at 21:12

Jakub TruhlářJakub Truhlář

8,84533 gold badges5151 silver badges6262 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  What happens if you do what the warning suggest and replace defer with do ?
  
  – David Rönnqvist
  Mar 27 at 21:27
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  What happens if you place foo = bar at the end of the deinit without defer?
  
  – Ron
  Mar 27 at 21:40
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  In both cases the observer of the property would not be executed. Suggested do itself would be redundant and observers don't run in the init and deinit.
  
  – Jakub Truhlář
  Mar 27 at 22:31
  

  
  
  
  

add a comment | 

Since the Xcode 10.2 (Swift 5) the defer statement at the end of the deinit scope produces:

'defer' statement before end of scope always executes immediately; replace with 'do' statement to silence this warning

Let's take a look at this example:

var foo: String 
 didSet 
 // smt
 


deinit 
 defer <--- Warning
 foo = bar
 

• Of course it's possible to get rid of this warning by moving the code from the observer to a method and call it explicitly but…

What's the point of this warning? - Isn't it reasonable to have the defer statement in the deinit? (e.g. to be able to trigger properties' observers).

swift deinit property-observer

share|improve this question

asked Mar 27 at 21:12

Jakub TruhlářJakub Truhlář

8,84533 gold badges5151 silver badges6262 bronze badges

var foo: String 
 didSet 
 // smt
 


deinit 
 defer <--- Warning
 foo = bar
 

share|improve this question

asked Mar 27 at 21:12

Jakub TruhlářJakub Truhlář

8,84533 gold badges5151 silver badges6262 bronze badges

share|improve this question

asked Mar 27 at 21:12

Jakub TruhlářJakub Truhlář

8,84533 gold badges5151 silver badges6262 bronze badges

asked Mar 27 at 21:12

Jakub TruhlářJakub Truhlář

8,84533 gold badges5151 silver badges6262 bronze badges

asked Mar 27 at 21:12

Jakub TruhlářJakub Truhlář

8,84533 gold badges5151 silver badges6262 bronze badges

1 Answer
1

active

oldest

votes

4

The warning is correct in that the use of defer here doesn't change the order of execution of your program, which is what the statement is designed for. It is however unfortunate that the suggested replacement otherwise changes the behaviour of your program (filed a bug: SR-10207).

It's worth noting that the use of defer to trigger a property observer is a bit of a hack that only works because the type checker considers it to be a different context to the deinit body. You can also achieve the same result with a closure expression:

 deinit 
 foo = bar ()
 

Ideally, there would be some form of syntax that lets you tell Swift "don't perform a direct-to-storage access here", so that such workarounds aren't necessary, but there isn't currently.

A less hacky workaround is to pull out the desired logic of the deinitialiser into a separate method, which puts the logic in a context where property accesses are done normally:

class C 
 var bar = ""

 var foo: String 
 didSet 
 // smt
 
 

 init(foo: String) self.foo = foo 

 private func doDeinit() 
 foo = bar
 

 deinit 
 doDeinit()
 

share|improve this answer

edited Mar 27 at 22:18

answered Mar 27 at 21:41

HamishHamish

53.9k99 gold badges126126 silver badges191191 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thanks, I was wondering if this is some kind of defer statement misuse but I guess not. A defer statement defers execution until the current scope is exited, so for me - it is not inside the scope in the time of execution. And the suggested replacement is indeed unfortunate. It seems like a flaw.
  
  – Jakub Truhlář
  Mar 27 at 22:43
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @JakubTruhlář Not quite – from the Swift language guide: "A defer statement is used for executing code just before transferring program control outside of the scope that the defer statement appears in"
  
  – Hamish
  Mar 27 at 22:45
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Good point, would you consider the fact it triggers observers in theinit/deinit a bug then? I guess the formulation of the defer part in the docs has changed - based on the open bug SR-1437
  
  – Jakub Truhlář
  Mar 27 at 23:04
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @JakubTruhlář I wouldn't really consider it a bug given that changing the behaviour now would be quite source breaking, as quite a few people rely on using defer to trigger property observers, and it doesn't quite meet the bar of "causing active harm" to warrant changing IMO. It's certainly unfortunate that we're stuck with this behaviour though.
  
  – Hamish
  Mar 27 at 23:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thank you for filing the bug report SR-10207 @Hamish.
  
  – Jakub Truhlář
  Mar 28 at 0:50
  
  

  
  
  
  

add a comment | 

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',
autoActivateHeartbeat: false,
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

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55386533%2fdefer-statement-at-the-end-of-deinit-produces-a-warning%23new-answer', 'question_page');

);

Post as a guest

Name

Email

Required, but never shown

4

The warning is correct in that the use of defer here doesn't change the order of execution of your program, which is what the statement is designed for. It is however unfortunate that the suggested replacement otherwise changes the behaviour of your program (filed a bug: SR-10207).

It's worth noting that the use of defer to trigger a property observer is a bit of a hack that only works because the type checker considers it to be a different context to the deinit body. You can also achieve the same result with a closure expression:

 deinit 
 foo = bar ()
 

Ideally, there would be some form of syntax that lets you tell Swift "don't perform a direct-to-storage access here", so that such workarounds aren't necessary, but there isn't currently.

A less hacky workaround is to pull out the desired logic of the deinitialiser into a separate method, which puts the logic in a context where property accesses are done normally:

class C 
 var bar = ""

 var foo: String 
 didSet 
 // smt
 
 

 init(foo: String) self.foo = foo 

 private func doDeinit() 
 foo = bar
 

 deinit 
 doDeinit()
 

share|improve this answer

edited Mar 27 at 22:18

answered Mar 27 at 21:41

HamishHamish

53.9k99 gold badges126126 silver badges191191 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thanks, I was wondering if this is some kind of defer statement misuse but I guess not. A defer statement defers execution until the current scope is exited, so for me - it is not inside the scope in the time of execution. And the suggested replacement is indeed unfortunate. It seems like a flaw.
  
  – Jakub Truhlář
  Mar 27 at 22:43
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @JakubTruhlář Not quite – from the Swift language guide: "A defer statement is used for executing code just before transferring program control outside of the scope that the defer statement appears in"
  
  – Hamish
  Mar 27 at 22:45
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Good point, would you consider the fact it triggers observers in theinit/deinit a bug then? I guess the formulation of the defer part in the docs has changed - based on the open bug SR-1437
  
  – Jakub Truhlář
  Mar 27 at 23:04
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @JakubTruhlář I wouldn't really consider it a bug given that changing the behaviour now would be quite source breaking, as quite a few people rely on using defer to trigger property observers, and it doesn't quite meet the bar of "causing active harm" to warrant changing IMO. It's certainly unfortunate that we're stuck with this behaviour though.
  
  – Hamish
  Mar 27 at 23:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thank you for filing the bug report SR-10207 @Hamish.
  
  – Jakub Truhlář
  Mar 28 at 0:50
  
  

  
  
  
  

add a comment | 

4

The warning is correct in that the use of defer here doesn't change the order of execution of your program, which is what the statement is designed for. It is however unfortunate that the suggested replacement otherwise changes the behaviour of your program (filed a bug: SR-10207).

It's worth noting that the use of defer to trigger a property observer is a bit of a hack that only works because the type checker considers it to be a different context to the deinit body. You can also achieve the same result with a closure expression:

 deinit 
 foo = bar ()
 

Ideally, there would be some form of syntax that lets you tell Swift "don't perform a direct-to-storage access here", so that such workarounds aren't necessary, but there isn't currently.

A less hacky workaround is to pull out the desired logic of the deinitialiser into a separate method, which puts the logic in a context where property accesses are done normally:

class C 
 var bar = ""

 var foo: String 
 didSet 
 // smt
 
 

 init(foo: String) self.foo = foo 

 private func doDeinit() 
 foo = bar
 

 deinit 
 doDeinit()
 

share|improve this answer

edited Mar 27 at 22:18

answered Mar 27 at 21:41

HamishHamish

53.9k99 gold badges126126 silver badges191191 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thanks, I was wondering if this is some kind of defer statement misuse but I guess not. A defer statement defers execution until the current scope is exited, so for me - it is not inside the scope in the time of execution. And the suggested replacement is indeed unfortunate. It seems like a flaw.
  
  – Jakub Truhlář
  Mar 27 at 22:43
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @JakubTruhlář Not quite – from the Swift language guide: "A defer statement is used for executing code just before transferring program control outside of the scope that the defer statement appears in"
  
  – Hamish
  Mar 27 at 22:45
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Good point, would you consider the fact it triggers observers in theinit/deinit a bug then? I guess the formulation of the defer part in the docs has changed - based on the open bug SR-1437
  
  – Jakub Truhlář
  Mar 27 at 23:04
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @JakubTruhlář I wouldn't really consider it a bug given that changing the behaviour now would be quite source breaking, as quite a few people rely on using defer to trigger property observers, and it doesn't quite meet the bar of "causing active harm" to warrant changing IMO. It's certainly unfortunate that we're stuck with this behaviour though.
  
  – Hamish
  Mar 27 at 23:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thank you for filing the bug report SR-10207 @Hamish.
  
  – Jakub Truhlář
  Mar 28 at 0:50
  
  

  
  
  
  

add a comment | 

The warning is correct in that the use of defer here doesn't change the order of execution of your program, which is what the statement is designed for. It is however unfortunate that the suggested replacement otherwise changes the behaviour of your program (filed a bug: SR-10207).

It's worth noting that the use of defer to trigger a property observer is a bit of a hack that only works because the type checker considers it to be a different context to the deinit body. You can also achieve the same result with a closure expression:

 deinit 
 foo = bar ()
 

Ideally, there would be some form of syntax that lets you tell Swift "don't perform a direct-to-storage access here", so that such workarounds aren't necessary, but there isn't currently.

A less hacky workaround is to pull out the desired logic of the deinitialiser into a separate method, which puts the logic in a context where property accesses are done normally:

class C 
 var bar = ""

 var foo: String 
 didSet 
 // smt
 
 

 init(foo: String) self.foo = foo 

 private func doDeinit() 
 foo = bar
 

 deinit 
 doDeinit()
 

share|improve this answer

edited Mar 27 at 22:18

answered Mar 27 at 21:41

HamishHamish

53.9k99 gold badges126126 silver badges191191 bronze badges

 deinit 
 foo = bar ()
 

class C 
 var bar = ""

 var foo: String 
 didSet 
 // smt
 
 

 init(foo: String) self.foo = foo 

 private func doDeinit() 
 foo = bar
 

 deinit 
 doDeinit()
 

share|improve this answer

edited Mar 27 at 22:18

answered Mar 27 at 21:41

HamishHamish

53.9k99 gold badges126126 silver badges191191 bronze badges

answered Mar 27 at 21:41

HamishHamish

53.9k99 gold badges126126 silver badges191191 bronze badges

answered Mar 27 at 21:41

HamishHamish

53.9k99 gold badges126126 silver badges191191 bronze badges