Liebes #fediverse, ich habe gerade einen etwas persoenlichen Aufruf:

Bei Paula, der besten Freundin meiner Tochter, wurde Anfang des Jahres #Leukämie diagnostiziert. Sie ist derzeit auf der Suche nach einem Stammzellspender. Es wuerde meiner Tochter und mir sehr viel, und Paula und ihrer Familie alles bedeuten, wenn ihr euch ihre Seite bei der #DKMS ansehen wuerdet:
dkms.de/aktiv-werden/online-ak

Vielen Dank! Ich freue mich auch ueber #Boost dieser Nachricht!

@helge @phranck Just checked. With the extension in the same module Swift 5.6.1 on x86_64 will remove the call for a different platform. For the same platform it won’t inline the modifier though and still does the runtime check. If it happens in a real app project is a different story, of course. But as I suspected - it is possible.

@helge @phranck why so sure? Of course it has to be inlineable, so either in the same module or declared as such.

@helge @phranck I wouldn’t be surprised if the compiler was able to optimise away the code for the other platforms

@helge haven’t done any measurements yet, but I would expect the struct to be faster after a certain number of subviews, since they will have to be dogged as well if the body was evaluated.

@helge Careful though, their behavior slightly differs. The function will always be evaluated when its superview body is evaluated. The body property of your struct will only be evaluated when it’s state changed. So there may be some performance impact

@krzyzanowskim I see what you mean, didn’t consider those property wrappers that can access the enclosing instance.

But I still would say they compose just fine, it’s just that there are some wrappers you cannot combine with others. You also wouldn’t expect to be able to combine a read-only wrapper and one that needs to modify itself.

@selfcare If you’re using iOS or macOS the Screen Time feature is great for that.

@krzyzanowskim What do you mean? They compose just fine. Haven’t needed that yet though.

@krzyzanowskim I use them a lot outside of SwiftUI. You can do some cool stuff with Codable and property wrappers.

I like ignoring unknown enum cases when decoding: 5sw.de/2022/01/unknown-enum-ca

There are 10 kinds of people in this world: Those who understand binary, those who don't, and those who weren't expecting a base 3 joke. 😅

@loveisanalogue sure. But first things will get worse. The question is for how bad is it going to get, and for how long

@breakthesystem why would you want to do that? The only case I see where this would help is when you have a bug somewhere that allows you to change state without notifying the UI.

Ich habe mich die Tage mit Freunden über Corona-Fälle in der Bekanntschaft unterhalten. Wir hatten einen unterschiedlichen Blick auf die Anzahl der Infektionen.

Ich würde zum Abgleich gern mal von euch wissen, wie oft ihr bisher mit infiziert wart:

(RT sehr erwünscht)

@oa Mit GoAccess hab ich mich heute auch beschäftigt. Hast du es hinbekommen die Websocket-Verbindung durch nen Proxy zu schleifen?

@pixel Just be careful not to overuse ViewBuilder methods or properties to extract parts of a view. Those will have to run every time your view is rendered. If you extract the views to a separate View struct the body will not be evaluated if none of its properties changed.

@blindcoder I work a lot with (very) junior developers. Always interesting to see what they are struggling with, and what they understand easily. Quite often rather surprising for me.

@blindcoder

I don’t think the first one is easier to read for anyone, but especially not for beginners. Too many irrelevant details to keep track of, and possibly get wrong.

The foreach-Syntax can also do more. It will happily loop over sequences where you can’t know the length before or access elements by index.

But in the end I don’t think this has any real impact on code quality. Nothing really changed if you replace one with the other.

Show older