I'd like to say that I genuinely appreciate the effort you're making to help me out. I don't want you to feel that I'm ungrateful. Having said that, I can't see where you're getting the information that Binding doesn't cause a view to update. That's the whole purpose of a binding. The difference between State and Binding, is where the data is 'owned'. While the syntax has changed a few times over the years, currently State declares where the data is instantiated and held. Binding declares the data is owned elsewhere, and "loaned" to the subviews with a 2-way binding to the parent. In any case, as it turns out, the problem in my demo code was me using .constant() in the preview (so the value wasn't changing). The optional binding does work when I alter the demo code to use a state value in the parent code. I'm going to have to do some more investigation to why it's not working in my full app, then try to simplify from there.

[quote='856132022, Claude31, /thread/798767?answerId=856132022#856132022, /profile/Claude31'] Yes, and that was my initial question: to what is it passed ? [/quote] The question confused me. You were talking about the binding being passed to something. But clearly it's being passed to the TextField, so I figured I must be misunderstanding what you were meaning.

I think we're getting a bit distracted here. @Binding exists and has many valid uses. The issue I am encountering is that a passed in binding isn't getting updated by a TextField, while a @State binding does work. It's either a bug or it's by design. That is the question I'm wanting to get an answer to. I can't think of it being by design as it displays the value fine, just not update it.

Thanks for making the effort to answer. The code I posted was simply to demonstrate the inconsistency. In my actual project there's a model instantiated by the main file, with bound properties passed into the subviews. As such, I can't replace the binding with a local state. Looking at your code, it's interesting that the boundValue var you've done in the subview does work. I'll have to do some trial and error to figure out what's causing the difference. (Only immediate difference I can see is in your code, the bound value is being created in a View.)

I've encountered this myself. However, it appears that optional value bindings work for @State properties but not for @Binding ones.

@Claude31 , I thought I'd give you an update. Played around with your suggestion a bit, and managed to get something close. This is the code I ended up with. class Point { var x, y: Int init(x: Int, y: Int) { self.x = x self.y = y } } class SubPoint: Point { var z: Int init(x: Int, y: Int, z: Int) { self.z = z super.init(x: x, y: y) } } @dynamicMemberLookup struct PassthroughWrapper<T> { var value: T subscript(dynamicMember member: KeyPath<T, Int>) -> Int { return value[keyPath: member] } } let point = SubPoint(x: 2, y: 3, z: 5) let wrapper = PassthroughWrapper(value: point) print(wrapper.z) Or, in my case @dynamicMemberLookup struct PassthroughWrapper<T: ElectronicComponent> { var value: T subscript(dynamicMember member: KeyPath<T, Lead>) -> Lead { return value[keyPath: member] } } let resistorC = Resistor("R3", resistance: .init(value: 50, unit: .ohms)) let wrapper = PassthroughWrapper(value: resistorC) print(wrapper[dynamicMember: \.output]) } To elucidate, making the structure generic, things do work as I had been wanting – almost. While everything appears to works as desired, it requires creating a wrapper for every component used. Which feels like it's negating the goal of creating connections less code. Thanks to your suggestion, I have learned new things and new approaches. Perhaps I can repay your 1c, one day. ;-)

Thanks for the suggestion. 1 cent is not valueless when someone has nothing! This is my first venture into implementing dynamic member lookup. I'm at the stage where I believe I understand it – until I have to explain it, at which point I realise I really have no idea. Your suggestion gave me a momentary epiphany about a possible solution, so tried to understand the code better. At this stage, I'm thinking it still won't achieve my goal – having the compiler behave as though the method had been inherited by the subclasses, including auto-complete. FYI Following @DTS Engineer Quinn's suggestion, I've reposted the question at swift.org, but essentially given up on the approach I was hoping for. Having said that, your comment still feels worth exploring to see how far I can get.

To clarify, the code I'd like to be able to use is line 55 in the above code block.

This is (for me) a common initialisation issue in Swift. You aren't able to use properties to calculate other properties until the type is fully initialised – which it can't be as you're still allocating values. AFAIK you have to either make those variables lazy (which then makes the struct mutate when you access those variables, which can be a pain) or you set them in an explicit initialiser.

Thanks for your response. There are so many hidden rocks under the surface of technology that take a lifetime to discover. I would be interested in hearing what tools are available. Even the ones I know about in instruments overwhelm me in detail and I can't imagine what usable information there could be in the haystack of stochastic simulations over multiple cores. I think I'll experiment with shifting where the concurrency occurs in my simulation (e.g. whether it's better to have two independent tournaments simulated in parallel, or have one simulation with matches "playing" at the same time) and see what I discover.

I note that it is listed as a "known issue" in beta 3. That could mean it inadvertently stopped working with this release. A major intentional change like that would be surprising in a beta version update. You'd imagine it to have happened going from 13->14b1.