Leonardo's example makes the case for why Swift should adopt a 'sealed'
keyword that can be used to make public classes non-subclassable outside
the module where they are defined, but not for why this should be the
default.
Others have made these points before, but these are the two biggest reason
On Mon, Jun 13, 2016 at 12:21 PM Xiaodi Wu wrote:
> On Mon, Jun 13, 2016 at 12:20 PM, let var go wrote:
>
>>
>>
>> On Mon, Jun 13, 2016 at 9:46 AM Xiaodi Wu wrote:
>>
>>> On Mon, Jun 13, 2016 at 11:41 AM, let var go wrote:
>>>
On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu wrote:
>>
On Mon, Jun 13, 2016 at 8:54 AM Erica Sadun wrote:
>
> On Jun 13, 2016, at 9:44 AM, let var go via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think we must be reading different discussions.
>
> What I have seen in this discussion is the following:
>
On Mon, Jun 13, 2016 at 8:26 AM Erica Sadun wrote:
>
> > On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I am 100% with Charlie on this. Expressiveness has to do with the
> *effectiveness* of conveying a t
On Mon, Jun 13, 2016 at 9:46 AM Xiaodi Wu wrote:
> On Mon, Jun 13, 2016 at 11:41 AM, let var go wrote:
>
>>
>>
>> On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu wrote:
>>
>>> Moreover, I should add, if your goal is to eliminate the possibility of
>>> continuing and breaking from inside the loop, `.f
Well, the "harmful" nature of it is something that still hasn't been
established as far as I'm concerned. I came to this discussion a little
late, but after reading through as many old email comments as I could find,
the only harm is an undocumented report that somewhere there were some
relatively
No, the key difference between for...in and forEach is that for...in allows
for early exit. They both allow you to 'continue', though in forEach it is
called 'return':
// This prints odd numbers, skipping ("continuing") past the even numbers:
(0..<100).forEach { if $0 % 2 == 0 { return } else { pr
On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu wrote:
> Moreover, I should add, if your goal is to eliminate the possibility of
> continuing and breaking from inside the loop, `.forEach()` does that
> exactly, so your argument would be for the elimination of `for..in`
> altogether.
>
I have no "goal"
No, I wouldn't eliminate 'continue'. Even though I consider it a
sub-optimal solution, I would keep it in the language. Why? A couple of
reasons:
1) I don't like it, but even 'continue' may be the best available solution
in the context of a particular problem. I will look for other options
first,
I sincerely apologize for singling people out. I will avoid it in the
future. I can see how it might personalize things in a way that is bad. I
appreciate you pointing out my mistake :)
On Mon, Jun 13, 2016 at 8:54 AM Erica Sadun wrote:
>
> On Jun 13, 2016, at 9:44 AM, let var go via
I think we must be reading different discussions.
What I have seen in this discussion is the following:
a) The need to filter a for-in loop doesn't arise that often; but,
b) When it does arise, everyone who has chimed in on this thread (except
the two people who are proposing the change) thinks t
I am 100% with Charlie on this. Expressiveness has to do with the
*effectiveness* of conveying a thought or a feeling.
Keep "where". It is expressive. It conveys a specific idea effectively and
concisely.
On Mon, Jun 13, 2016 at 7:54 AM Charlie Monroe via swift-evolution <
swift-evolution@swift.o
I respect that anti-goal, but I think being over-rigid about limiting
developers' choice of expression is also an anti-goal.
To me, it is like guard statements vs. if-let statements. Some people find
one to be more clear than the other. Often times the best choice depends on
the context. Sometimes
Leave it in!
It's a great little tool. I don't use it very often, but when I do it is
because I've decided that in the context of that piece of code it does
exactly what I want it to do with the maximum amount of clarity.
If you don't like it, then don't use it, but I can't see how it detracts
fr
14 matches
Mail list logo
