Dan Wineman

@dwineman @gte Code doesn't work as is, and switching the second "class Base" to "extension Base" in the REPL doesn't repro...

@dwineman @gte I believe so; ran in `xcrun swift -integrated-repl -sdk $(xcrun --show-sdk-path --sdk macosx)`

@PowerUser @gte I just tried the same. "extension Base" doesn't repro in the REPL, but replacing the first "class Base" does. Very odd.

@dwineman @gte I suspect a playground implementation artifact, then; Much more palatable than the idea of semi-dynamic scope.

@PowerUser @gte Well, how do we know where the artifact is? Also, it's still a FBC issue. Hard to test that sort of thing interactively.

@dwineman @gte For the first? Compiled behavior should be definitive, I think… and if scoping is lexical, then it shouldn't represent FBC.

@dwineman @gte doesn’t C++ behave exactly the same in this case?

@NachoSoto @gte Not familiar enough with C++ to say, but if so, that’s a bad thing :-)

@dwineman @gte I don’t see why :/ the instance method takes higher precedence than the function.

@dwineman its been years since you've been in my timeline. good to see you made it out alive! /cc @gte

@rudyrichter @gte Um, thanks?

@dwineman made it out alive from your last employer. /cc @gte

@dwineman @gte I'm not really seeing the issue. It makes sense to me. What doesn't make sense it calling a local method from within a class.

@drumnkyle @gte Swift is heavy on generics. Lots of things are implemented as functions instead of methods. sort(), countElements(), …

@dwineman @gte Ok. I see that, but doesn't change the fact that from what I would think, you would want your own implementation to override.