> Karl Wagner: In Plato's Crito, Socrates refuses to flee Athens after being
> sentenced to death. He entered in to an agreement with the state to
> participate in the process and respect its judgements, and reasons that to
> violate the rules of the system because he believes the outcome
> Brent Royal-Gordon: Something to keep in mind when you write your proposal:
> At least one member of the core team has expressed a desire for regular
> expressions to be deeply integrated into the language, with strong
> connections to `case` syntax and destructuring, and a Perl 6-style
A warm -0.5 from me, meaning that I agree that this issue is important to
address, and that I concur with many of the particulars. (I agree that removing
is way better than drop, for example.)
However, I suspect that this approach may open more Pandora’s boxes than it
closes. Most of my
+1
[ Long, sorry… ]
This version is a big step forward! Thanks for the continued work and
comments...
I want to propose a small reframing that I think would help to clarify some of
the remaining issues. It’s not really a “counterproposal” because I don’t think
it actually changes all that
> Brent Royal-Gordon: If, as seems likely for lens support, we eventually
> supported inout functions:
>
> func foo(x: Int) -> inout String {
> get { return myStr }
> set { myStr = newValue }
> }
>
> Would you feel differently about having `:` on
+1
I prefer the current syntax from a subjective and readability perspective.
However, the current notation of -> Type being used to declare an input
parameter to set {} just strikes me as weird and wrong. The symbol -> means
“returns a” or “yields”. Since we’re declaring a type that might be
> Taras Zakharko: I did a quick rudimentary regex through AppKit headers
> looking for stuff like "((n't)|(not)).{1,15}override“ and its true that there
> seem to be only a few dozens of documented methods where the documentation
> explicitly warns agains overriding them. I have no idea how
+1. Write it up.
Garth
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
> Liam: ...my proposal has been marked as out of scope for swift 3.0, so we'll
> have to wait a month or so to bring this back up again.
That seems reasonable, but I _would_ like to see this come up for discussion.
IMHO, cases such as
let token = authorize(user?, password?, operation?)
are
Károly demonstrated that it’s already possible to achieve the effect of a
nonoverridable method:
> public open class UIViewController {
> private var _view: UIView? = nil
>
> public final func loadViewIfNeeded() {
> internalLoadViewIfNeeded()
> }
>
>
> Károly wrote: I suggest we change the proposal to remove the implicit
> "sealed" level of public member overridability, and support only "open" or
> "final" class members. For members, "open" should mean the opposite of
> "final", with no levels in between. Member-level openness should be
Is there a summary somewhere of the motivation for allowing methods to be
declared non-overridable within open classes?
I’m not asking about any particular syntax or default, just why you'd want this
facility at all. The proposal doesn’t mention this, and the discussion of the
initial version
> Tino Heth wrote: ...I challenged [supporters] to show a singe persuasive
> example to illustrate that this proposal could actually improve
> something...even if there are cases which cannot be repelled with the simple
> advice "just don't subclass", this would only be a basis to start talking
Strong -1 from me.
I think most of my thoughts on this have already been well covered by others.
I’ll just note that this proposal reminds me of the fortune file entry,
“Whenever you see a sign that says ‘no exit’, it means there is an exit there.”
Specifically, under this proposal, whenever
14 matches
Mail list logo
