Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Cihat Gündüz via swift-evolution]

@Jan: Your arguments are very subjective if not even insulting and derogatory 
to many people who invest a lot of time and effort in crafting those things you 
despise so openly. Here are just a few example quotes for you to reflect your 
language:

"I despise fp“, „is so annoying“, "made Swift imo a worse language“, "I hate 
‚modern' or as I call it ugly“, "Today’s standards are a bag of pain“, "crappy 
sites als Facebook, Twitter, Instagram, Stackoverflow, add lots of other 'cool' 
sites“, "I can’t stand scrolling“, "I hate both“, "todays absolutely useless 
crap“, …

Please be aware that this behavior is against the Code of Conduct of the Swift 
Community. Let’s try to stay objective and justify different opinions 
rationally instead of personally. Of course it is valid for you to say that you 
don’t like FP or that you don’t like how the world is changing in general. But 
please be aware that you have to add the reason why you think it is so in 
detail, so we understand your thinking and can overcome changes to the wrong 
direction. Senctences like „I despise FP“ without any explanation are not a 
form of constructive feedback though, nobody will learn anything from that kind 
of thing. Currently you’re merely expressing your anger here, no more, no less.


@Jens: One of the biggest reasons I’m all for Discourse is the fact that it’s 
open source. What this implies is: You know exactly what happens with the data 
you save there, and, there is no dependency on a third-party service which 
could change or even close over time. This is why I’m against groups.io, GitHub 
Issues or any other non-open source solution. What it also means is: If the 
open source tool we decided to go for (Discourse) doesn’t have good support for 
emails yet, we can implement it ourselves, improve the existing support or add 
a bridge to another open source tool that can deal with that.

-- 
Cihat Gündüz

Am 9. Februar 2017 um 15:59:33, Jan Neumüller via swift-evolution 
(swift-evolution@swift.org) schrieb:

Well, if the community likes it so much. Have fun with it. I will leave as I 
have left the Developer Forums at Apple because they became unusable.


On 9 Feb 2017, at 15:17, Adrian Zubarev  wrote:

The quote below made my day dear Swift friend as I might remind you that if 
modern is associated with hate in your mind, then the modern programming 
language called Swift would probably be a bad choice. 


I starting to think that myself. I was very active at the beginning of Swift 
(way before the open sourcing) but I absolutely don’t like the increasing 
influence of functional programming on it. I despise fp and don’t want it in 
Swift. If people want it that much use Haskell 8(
I might remind everyone that Discourse is open sourced and therefore tweaks are 
possible. If you prefer a consistent font like on swift.org, than spell it out 
and help to create a corner on the web where every Swiftier feels right at 
home. 


I don’t think that Discourse is salvageable but go on. But I don’t know how one 
could rip out this big piece of JavaScript and keep ist functional.
Personally I’d prefer (if possible) that we’d remove profile pictures from the 
forum and simply have only full names (colored?) + some kind of annotation 
(e.g. Core Team, etc.). Profile pictures are only gimmicks that does not 
contribute to anything at all.

As Jan already said, the font (and font-size?) of the forum could match the 
font from swift.org if possible. I wouldn’t mind and it’d make it a little bit 
more alike.


You don’t have to care for me - Swift 4 will be the deciding step if I throw 
any Swift work away and return to Objective-C. The heavy functional programming 
push since open sourcing is so annoying and made Swift imo a worse language.

Jan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Cihat Gündüz via swift-evolution]

After trying out Nate Cook’s Discourse test server I’d like to add a few things 
on my previous message:

#1 I found the beginning of this threads discussion without any problems (both 
from navigating through the threads structure and from the search feature) 
which was interesting for me, as I couldn’t do that in my mail client given 
that I opted in to the mailing list later on. Especially the fact that at the 
beginning Discourse wasn’t even suggested of the original post was interesting. 
I wouldn’t have known that without the Discourse test server.

#2 Following a discussion is much easier in general, but I noticed one downside 
(I guess that’s one of the hurdles to be addressed): Some quotes within emails 
were imported to threads in a way that makes reading actually much worse. See 
this thread as an example. The initial messages is repeated over and over 
again, and since it’s very long scrolling all the time is really annoying here.

#3 I really like the fact that Discourse makes it very simple to get an 
overview of all the current discussion threads. For example, I opened the Swift 
Evolution category and could see immediately all threads that I’m aware of 
since I saw new messages coming in my inbox – but many more, that I wasn’t 
aware of where discussion seem to have cooled down for a while. That’s really 
convenient!

Mostly following the discussion is much simpler on Discourse, so my previous 
claim that it would solve all my problems seem to be true. I’d really like to 
see this getting to Discourse. Then I would even be able to send my fellow 
Swift developers links to discussions and they would actually read them – this 
would improve the quality of our internal best practice discussions a lot.

-- 
Cihat

Am 4. Februar 2017 um 16:13:32, Ben Rimmington via swift-evolution 
(swift-evolution@swift.org) schrieb:


> On 26 Jan 2017, at 18:02, Nate Cook wrote:
>  
>> On Jan 25, 2017, at 3:32 PM, Douglas Gregor wrote:
>>  
>> I’ve looked into Discourse a bit, and it does look very promising. One 
>> *specific* way in which a motivated individual could help would be to take a 
>> look at Discourse’s import scripts and try importing swift-evolution’s 
>> mailing archives with them. We absolutely do not want to lose history when 
>> we switch technologies. Do the messages import well? Are threading and 
>> topics maintained in a reasonable manner? Does Discourse provide effective 
>> UI for looking into past discussions on some specific topic we’re interested 
>> in?
>  
> ✋
>  
> I forged the mighty, turgid rivers of rubyenv, hand-tweaked gem dependencies, 
> and sed-cleaned mbox files to try this out—you can see the results of an 
> import (using one or two day old data) at this address:
> http://discourse.natecook.com/

Discourse doesn't properly import names with an acute accent:




I'm not sure why "=?utf-8?Q?F=C3=A9lix_Cloutier?=" isn't automatically decoded 
by the Mail library:






-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Cihat Gündüz via swift-evolution]

I can only say how I perceive the mailing list from my own perspective:

The mailing list is a really confusing way of following the discussions for me. 
I never know the context of an answer since my mail clients don’t show the 
quoted parts correctly. Also I get a lot of emails throughout the day on all my 
devices (including my Apple Watch), even when I’m really not into reading them. 
I’d have to create an extra email account or setup some magic filtering to fix 
this, also make sure I get push notifications only for those other accounts 
etc. – but this is all too much overhead. Therefore the only options for me 
are: Get all emails or get none. Everything else it too complicated to 
configure, given that I just want to read some threads that sound interesting 
to me and maybe post some ideas here and there.

Discourse is a tool that I like very much and find very clean and 
understandable. Also it has a thread-summarize feature which would help a lot 
to get an overview of longer-discussed threads for those of us coming in later 
on. Note that I once followed the mailing list at the relative beginning of the 
open source Swift project and stopped doing that simply because it was too many 
emails that came into my mailbox that I didn’t care about. And that’s what I’m 
experiencing now again given that I opted in since a week or so now.

What I actually wanted or expected Swift Evolution for me to be was a go-to 
solution which I can open when I have time and read about discussion on one 
side and help out with ideas or vote on some issues on the other. I’ve tried 
Hirundo, I have even tried a folder which contains all Swift threads, I tried 
Apple Mail and Airmail 3 – but none of them was simple or useful enough, I 
could never find what I was looking for. Maybe I’m just too stupid for this 
mailing list, but one thing I know for sure: Discourse would have definitely 
solved this problem for me. I wondered from the beginning, why a big company 
like Apple would ever even consider choosing such a poor and unclean interface 
like a mailing list for discussions. I thought I’m missing something and it’s a 
lot more productive and tried to use it – but it simply doesn’t fit my needs.

I can understand how a mailing list is interesting if you are working on 
developing Swift all-day and don’t want to miss any message. But for the open 
source from-time-to-time contributors and followers of the Swift evolution 
discussions I don’t think email is a good solution. Discourse would be great 
for these cases. So, for me personally, if Discourse (or a similar alternative) 
isn’t considered and tried to be introduced, it means that the goal of Swift is 
not to have a broad contributing community but rather a small group of people 
who invest a lot of time to improve the Swift language. Earlier I didn’t think 
like that, I didn’t think about it at all, I just accepted the mailing list 
with „it is, what it is“. But now that I know others feel the same or similarly 
and therefore the guys at Apple are aware of the problem, I’m feeling like 
this, like that this is a question of how broad the community should be. I’d 
like to be a part of it, but the mailing list is not my thing. I’d probably 
drop out soon again … so this is what I think. It might not be of any value for 
the community, but maybe it’s a voice that wants to be heard, so I’m letting 
you hear it.

-- 
Cihat Gündüz

Am 2. Februar 2017 um 22:47:11, Dave Abrahams via swift-evolution 
(swift-evolution@swift.org) schrieb:



> On Feb 2, 2017, at 12:58 PM, Karl Wagner  wrote:
>  
> somebody build a parallel site to support the style of open community which 
> the core-team seem unwilling/unable to do.

I don't think this is fair. We may not be moving as quickly as you'd like but 
we are looking into it.  

Sent from my moss-covered three-handled family gradunza
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Add Array binary search to the standard library

[Cihat Gündüz via swift-evolution]

Hi guys, I know this topic is probably out of scope for Swift 4 and a proposal 
was already rejected for Swift 3, but I’d like to share my two cents on this as 
I just wrote a SortedArray class with support for binary search in my open 
source library HandySwift.

You can see my classes current implementation here:
https://github.com/Flinesoft/HandySwift/blob/cd7ae7041c8174cd655f24eae653f76697875a48/Sources/Structs/SortedArray.swift

My goal was to provide only what is commonly needed when working with big 
arrays in algorithms. For me this included:
- having a type that keeps a sorted array to prevent re-sorting (solution: the 
SortedArray class)
- have a method that can find an object using binary search (solution: the 
index method)
- allow partitioning the array into smaller parts (solution: subscript, prefix 
& suffix methods)
- prevent re-implementing the Array class (solution: a getter to the stored 
internal array)

Also note that the SortedArray in my approach allows all types that conform to 
`Sequence` as input with `Comparable` elements and saves them into a sorted 
array on initialization. That array is also publicly read-accessible. Inserting 
and deleting objects from the SortedArray are possible, too, but that’s just 
few of the MutableCollection methods. I didn’t want the SortedArray to conform 
to MutableCollection or even RandomAccessCollection as I felt it was not needed 
just to support binary search and prevent re-sorting.

Maybe my approach can somehow help forming the final solution to be included 
into Swift once this features is tackled again.

Best regards,
Cihat
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Cihat Gündüz via swift-evolution]

> However, you may be interested in the last email Chris sent in this chain 
> with regards to shortening it to just "let foo":
> 
> "This is commonly requested - the problem is that while it does help reduce 
> boilerplate, it runs counter to the goal of improving clarity."
> 
> He's got a point; "if let foo = bar" makes sense in a way, but just "if let 
> foo" is a bit nonsensical to me when I take my mind outside of the narrow 
> swift mindset I tend to get into. This extends to decorating the foo with a 
> question mark or a bang, imo. 

Thank you for the feedback, Dennis. That post you quote is amongst the ones I 
read and it is even the reason I am suggesting these alternatives. Let me 
explain my thinking behind my suggestions a bit. I agree with Chris that `if 
let foo { /* code */ }` isn’t very readable mainly because there is no action 
done on the `foo` like a `= bar` or something else. But I also had the thought 
‚why do I need to type this twice, can’t this be optimized?‘ quite a few times 
when I used `if let foo = foo { /* code */ }` in practice.

So that’s why I thought there must be a way. First I started with something 
that contained the `=` sign also using the shorthand `x += 1` for `x = x + 1` 
as an inspiration. That lead to things like these:

if let foo = _ { /* code */ }
if let foo = ! { /* code */ }
if let foo ?= _ { /* code */ }
if foo ?= foo { /* code */ }
if let foo ?= { /* code */ }

But being honest to myself I thought all of those were even less readable then 
`if let foo { /* code */ }`. But once I dropped the `=` sign like in `if let 
foo! { /* code */ }` I started to like the idea and still found it readable.

I generally read let like a ‚define constant with name‘ and a ! like ‚force 
unwrap value‘ so I would read `let foo!` as ‚define constant with name and 
force unwrap value`. But I agree that ? may be more correct which I read as 
`try to unwrap value only continuing if unwrap succeeds` so `let foo?` would 
read as `define constant with name and try to unwrap only continuing if unwrap 
succeeds`.

So in conclusion to me `if let foo { }` isn’t readable but `if let foo? { }` 
is. That is only my opinion though.

> 
> On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz  > wrote:
> I’ve only read the last couple of posts but has anybody already suggested 
> using something like this:
> 
> if let foo! {
>   // code that uses foo
> }
> 
> People already know that the ! is unwrapping a value and that let is defining 
> a new constant. So why not combine those two?
> Alternatively it could also be:
> 
> if let foo? {
>   // code that uses foo
> }
> 
> What do you think?
> 
> – Cihat
> 
>> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
>> >:
>> 
>>> 
>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution 
>>> > wrote:
>>> 
>>> I was going to suggest something similar (a hard naming problem also):
>>> 
>>> if has foo {
>>> // foo is now unwrapped and non-optional
>>> }
>>> 
>>> guard has foo else { return }
>>> 
>>> Does the same thing as `let foo = foo` in practice, but places it in a 
>>> somewhat different mental model. Instead of unwrapping and immediately 
>>> assigning to a new constant with the same name (which just looks kind of 
>>> silly, like some magic voodoo ritual), it sort of asserts that we “have” 
>>> foo (i.e. it’s not nil), and therefore from that point it can just be 
>>> treated as non-optional.
>>> 
>>> IMHO this, although introduces a new keyword, makes more sense than trying 
>>> to reuse “let” in a context where it seems nonsensical. Perhaps this would 
>>> be closer to Swift’s goals, by reducing very common boilerplate, but 
>>> without harming clarity in a way adding a new meaning to “let” would.
>>> 
>>> Curious to hear Chris Lattner’s opinion :-) 
>> 
>> IANACL (I am not a Chris Lattner) but, FWIW, several of us are uncomfortable 
>> with the idea that a single declared property might have different static 
>> types in different regions of code.
>> 
>>> 
>>> — Radek
>>> 
 On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution 
 > wrote:
 
 What if we made the keyword "unwrap"? 
 
 if unwrap someViewController {
 // now there is a shadowing nonoptional (unwrapped) variable of the same 
 name only within this scope, boiling down to simple syntactic sugar for 
 optional binding and it is fairly clear. 
 } 
 
 
 On Sat, Dec 19, 2015, 1:31 PM Kevin Wooten via swift-evolution 
 > wrote:
 As much fun as it to example with foo, I would argue the opposite when you 
 use some real world variable names:
 
 if let someInterestingViewConroller = 

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Cihat Gündüz via swift-evolution]

I’ve only read the last couple of posts but has anybody already suggested using 
something like this:

if let foo! {
  // code that uses foo
}

People already know that the ! is unwrapping a value and that let is defining a 
new constant. So why not combine those two?
Alternatively it could also be:

if let foo? {
  // code that uses foo
}

What do you think?

– Cihat

> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
> :
> 
>> 
>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution 
>> > wrote:
>> 
>> I was going to suggest something similar (a hard naming problem also):
>> 
>> if has foo {
>> // foo is now unwrapped and non-optional
>> }
>> 
>> guard has foo else { return }
>> 
>> Does the same thing as `let foo = foo` in practice, but places it in a 
>> somewhat different mental model. Instead of unwrapping and immediately 
>> assigning to a new constant with the same name (which just looks kind of 
>> silly, like some magic voodoo ritual), it sort of asserts that we “have” foo 
>> (i.e. it’s not nil), and therefore from that point it can just be treated as 
>> non-optional.
>> 
>> IMHO this, although introduces a new keyword, makes more sense than trying 
>> to reuse “let” in a context where it seems nonsensical. Perhaps this would 
>> be closer to Swift’s goals, by reducing very common boilerplate, but without 
>> harming clarity in a way adding a new meaning to “let” would.
>> 
>> Curious to hear Chris Lattner’s opinion :-) 
> 
> IANACL (I am not a Chris Lattner) but, FWIW, several of us are uncomfortable 
> with the idea that a single declared property might have different static 
> types in different regions of code.
> 
>> 
>> — Radek
>> 
>>> On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution 
>>> > wrote:
>>> 
>>> What if we made the keyword "unwrap"? 
>>> 
>>> if unwrap someViewController {
>>> // now there is a shadowing nonoptional (unwrapped) variable of the same 
>>> name only within this scope, boiling down to simple syntactic sugar for 
>>> optional binding and it is fairly clear. 
>>> } 
>>> 
>>> 
>>> On Sat, Dec 19, 2015, 1:31 PM Kevin Wooten via swift-evolution 
>>> > wrote:
>>> As much fun as it to example with foo, I would argue the opposite when you 
>>> use some real world variable names:
>>> 
>>> if let someInterestingViewConroller = someInterestingViewConroller {
>>> }
>>> 
>>> vs
>>> 
>>> If let someInterestingViewConroller {
>>> }
>>> 
>>> We know what let does and it should be enough to impart the necessary 
>>> information for this statement.
>>> 
>>> When it comes to newcomers I think you'd be hard pressed to find somebody 
>>> who'd be able to understand either form without teaching; so not losing 
>>> much there.
>>> 
>>> 
>>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
 
> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
> > wrote:
> 
> I’ve had similar ideas to this. Instead of ditching the if let syntax 
> altogether, another approach would be to use the existing name if no new 
> name is given, so that this code:
> 
>   if let foo = foo { /* use foo */ }
> 
> could become this code:
> 
>   if let foo { /* use foo */ }
> 
> In both cases, foo is non-optional inside the braces. If you gave it 
> another name with the if let syntax, that would work as it does today.
 
 Hi Jeff,
 
 This is commonly requested - the problem is that while it does help reduce 
 boilerplate, it runs counter to the goal of improving clarity.
 
 -Chris
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>>  ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>>  ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> 

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Cihat Gündüz via swift-evolution]

> Am 18.12.2015 um 21:02 schrieb Dave Abrahams <dabrah...@apple.com>:
> 
> -1 from me, if nothing else because the name is confusable with 
> multiplication in the context of integers.

Isn’t it a multiplication? A multiplication of the closure specified? I see it 
as such.

Also I don’t think many will confuse a method that takes a closure with the 
multiplication of two integers. I may be wrong, of course.

– Cihat

> 
>> On Dec 18, 2015, at 11:53 AM, Jacob Bandes-Storch via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I like how clean "100.times { doSomething() }" looks, but I'm concerned its 
>> usefulness will be limited because control-flow statements like 
>> break/continue/return won't work from inside a closure.
>> 
>> Jacob
>> 
>> On Fri, Dec 18, 2015 at 11:36 AM, Cihat Gündüz <swift-evolution@swift.org 
>> <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> Am 18.12.2015 um 20:13 schrieb Félix Cloutier <felix...@yahoo.ca 
>>> <mailto:felix...@yahoo.ca>>:
>>> 
>>> It doesn't need to be an underscore, but when it is not, the compiler emits 
>>> an educative warning steering you towards _:
>> 
>> It’s not about the underscore as a character, it’s about the fact that there 
>> is the clutter of an underscore at all what I don’t like and what makes me 
>> feel the code isn’t as clean as it could be.
>> 
>>> 
>>> /tmp/test.swift:3:7: warning: immutable value 'i' was never used; consider 
>>> replacing with '_' or removing it
>>> 
>>> You can also use inclusive ranges instead if you're more comfortable with 
>>> that: 1...5000 will do just that.
>> 
>> I’m comfortable with ranges but I also used to teach Java back a few years 
>> ago and I saw computer science students struggle with the exact number a 
>> loop was being executed. So that’s the only reason I brought up that example 
>> to have an additional argument.
>> 
>> But again, for me it is more about the clutter that the 1… or 0..< adds to 
>> something that could so easily made simpler and more descriptive.
>> 
>> I think this is also a question of: How many convenience methods do we want 
>> to see in the Swift standard library? In Ruby, at least, there seemed to be 
>> enough people to find this one useful. And it’s the first method I missed 
>> until now, so I took that as a sign before suggesting the addition. I also 
>> don’t like when there are thousands of convenience methods for things that 
>> could easily be written in other ways – but I don’t feel that way with the 
>> suggested .times method.
>> 
>>> 
>>> I don't mean to come across as dismissive, and I'm all for an inclusive 
>>> Swift that you can pick up without knowing advanced concepts. However, 
>>> there is definitely value in helping people learn, and learning always 
>>> moves you a little bit out of your comfort zone. When do we remove the 
>>> training wheels? How long can we hide the fact that indices usually start 
>>> at 0? How long before you need to iterate an array using the same 
>>> range-based for loop?
>>> 
>>> I spend a lot of time on Stack Overflow and I've seen lots of beginners ask 
>>> for lots of things, but the people who ask about the for loop are usually 
>>> people with a background in another C-like language who try to use the 
>>> arguably less readable C-like for loop. I've never seen anyone before say 
>>> that it looks unclean or unreadable.
>> 
>> I understand what you mean but I don’t think that this is about indices or 
>> beginners. The fact that readability and expressiveness make a language 
>> easier to learn for beginners IMHO is just a side effect of a well 
>> thought-out and developed language. Maybe I wasn’t clear enough but I want 
>> to see the .times method in Swift for my own usage, not for beginners. :)
>> 
>>> 
>>>> Le 18 déc. 2015 à 13:38:59, Cihat Gündüz via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>>> 
>>>> I agree with both of you about the alternative implementations.
>>>> 
>>>> That’s exactly what I’d love to see integrated to the standard library 
>>>> like Ruby is here:
>>>> http://ruby-doc.org/core-2.2.4/Integer.html#method-i-times 
>>>> <http://ruby-doc.org/core-2.2.4/Integer.html#method-i-times>
>>>> 
>>>> My main prob

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Cihat Gündüz via swift-evolution]

I agree with Radek. I find `for i in 5 { doSomething() }` or `for 5 { 
doSomething() }` to be very confusing since it is neither close to human 
language nor to any common programming language I know of.

I like the idea of giving students a step by step introduction into things, but 
this is IMO not the right way/place to do that.

– Cihat


> Am 18.12.2015 um 22:26 schrieb Radosław Pietruszewski via swift-evolution 
> :
> 
>> An obvious question is, should it be equivalent to 1...n, or 0.. 
> I think that’s exactly why this isn’t a good idea. The semantics of `for i in 
> 5` are not immediately clear at all.
> 
> If this was to be a language feature, `repeat 5`, suggested by Chris, seems 
> like the least-ambiguous choice.
> 
> — Radek
> 
>> On 18 Dec 2015, at 22:09, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>> This can be done pretty easily, although I think the approach has the 
>> potential to cause confusion elsewhere in code. An obvious question is, 
>> should it be equivalent to 1...n, or 0..> 
>> extension Int: SequenceType {
>> public func generate() -> RangeGenerator {
>> return (0..> }
>> }
>> 
>> for i in 5 {
>> print("hello \(i)")
>> }
>> 
>> Jacob Bandes-Storch
>> 
>> On Fri, Dec 18, 2015 at 1:03 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> > I’d like to propose an addition of a useful method, especially for 
>> > beginners that also makes Swift much more readable in some situations: The 
>> > addition of a .times method to Integer type(s).
>> 
>> I’ve said it before, but I don’t think `times` is a good solution for 
>> learners. It teaches them a form of looping they will never use in practice 
>> and does not allow them to practice with ancillary loop skills like `break` 
>> and `continue`.
>> 
>> I think our best bet is to extend the `for` loop to allow a single number, 
>> meaning either `1…n` or `0..> allow the `variableName in` part to be omitted, meaning `_ in`. This gives 
>> us the pedagogical simplicity of a “do this N times” loop, but couches it in 
>> a form where, when the student moves on, more commonly used loop forms are a 
>> straightforward extension of that simple case.
>> 
>> for 5 { print(“Hello!”) }
>> for i in 5 { print(“Hello \(i)!”) }
>> for i in 10..<20 { print(“Hello \(i)!”) }
>> for i in 10...20 { print(“Hello \(i)!”) }
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>>  ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution