Proposal: Python's "in" and "not in" syntactic sugar


(Amir Michail) #1

Examples:

if “hello” in [“hello, there”] { … }

if “hello” not in [“hello, there”] { … }


(Brent Royal-Gordon) #2

if “hello” in [“hello, there”] { … }

if “hello” not in [“hello, there”] { … }

Swift is extremely sparing with keywords in operator position; the only ones I can think of off the top of my head are `is` and `as`, and even those aren’t actually operators. You’re proposing to introduce one as syntactic sugar for [array].contains(elem), and introduce an even more bizarre two-word operator for ![array].contains(elem). I don’t think that’s gonna fly.

···

--
Brent Royal-Gordon
Architechies


(Amir Michail) #3

if “hello” in [“hello, there”] { … }

if “hello” not in [“hello, there”] { … }

Swift is extremely sparing with keywords in operator position; the only ones I can think of off the top of my head are `is` and `as`, and even those aren’t actually operators. You’re proposing to introduce one as syntactic sugar for [array].contains(elem), and introduce an even more bizarre two-word operator for ![array].contains(elem). I don’t think that’s gonna fly.

Most programmers would probably love using them though.

···

On Dec 17, 2015, at 9:51 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

--
Brent Royal-Gordon
Architechies


(Krzysztof Siejkowski) #4

Most programmers would probably love using them though.

Myself, I’d not love using them. I also don’t like them in Python.

But not to dismiss the idea on personal merits, could you please elaborate on the details of „in” and „not in” usage?

1) What types could they be used with? SequenceType? Array? Dictionary? Set? Optional?

2) Should their usage be extensible to any type? Will there be a possibility for a type Foo to participate in?


let foo = Foo()

if bar in foo {}

if bar not in foo {}

3) Will the operators be usable only in `if` statement? What about case, where clauses etc?

Krzysztof

···

--
Brent Royal-Gordon
Architechies

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


(Jeremy Pereira) #5

if “hello” in [“hello, there”] { … }

if “hello” not in [“hello, there”] { … }

Swift is extremely sparing with keywords in operator position; the only ones I can think of off the top of my head are `is` and `as`, and even those aren’t actually operators. You’re proposing to introduce one as syntactic sugar for [array].contains(elem), and introduce an even more bizarre two-word operator for ![array].contains(elem). I don’t think that’s gonna fly.

Most programmers would probably love using them though.

If that’s the case, I’d be in the minority.

I’d rather use [“hello", “there”].contains(“hello”). That might just be my background though which is heavily object oriented.

···

On 17 Dec 2015, at 15:59, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 17, 2015, at 9:51 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

--
Brent Royal-Gordon
Architechies

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


(Félix Cloutier) #6

I don't like it because it introduces a second way to do something that's already quite easy.

It's impossible for the Swift compiler to enforce that people never create a `contains` method (or create it without adhering to whatever protocol `in` uses behind the scenes), so in my opinion this would increase the burden of creating types that feel first-class.

As it's already been said before, Swift has been very careful with keywords so far. I wouldn't be in favor of introducing a keyword that replaces a method call.

Félix

···

Le 17 déc. 2015 à 10:48:02, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> a écrit :

On 17 Dec 2015, at 15:59, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 17, 2015, at 9:51 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

if “hello” in [“hello, there”] { … }

if “hello” not in [“hello, there”] { … }

Swift is extremely sparing with keywords in operator position; the only ones I can think of off the top of my head are `is` and `as`, and even those aren’t actually operators. You’re proposing to introduce one as syntactic sugar for [array].contains(elem), and introduce an even more bizarre two-word operator for ![array].contains(elem). I don’t think that’s gonna fly.

Most programmers would probably love using them though.

If that’s the case, I’d be in the minority.

I’d rather use [“hello", “there”].contains(“hello”). That might just be my background though which is heavily object oriented.

--
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


(Adrian Kashivskyy) #7

I agree with Felix.

I wouldn't be in favor of introducing a keyword that replaces a method call.

Note that `not in` operator actually consists of two operators – `not`, which would be an alias for `!` and `in` which would be an alias for `contains()`.

As said by my preceding speakers, there are no operator-like keywords in Swift so far, and In my opinion, there shouldn't be any.

By the way,

Most programmers would probably love using them though.

Please do no speak in the name of majority without actual numbers. :slight_smile:

Pozdrawiam – Regards,
Adrian Kashivskyy

···

Wiadomość napisana przez Félix Cloutier via swift-evolution <swift-evolution@swift.org> w dniu 17.12.2015, o godz. 17:16:

I don't like it because it introduces a second way to do something that's already quite easy.

It's impossible for the Swift compiler to enforce that people never create a `contains` method (or create it without adhering to whatever protocol `in` uses behind the scenes), so in my opinion this would increase the burden of creating types that feel first-class.

As it's already been said before, Swift has been very careful with keywords so far. I wouldn't be in favor of introducing a keyword that replaces a method call.

Félix

Le 17 déc. 2015 à 10:48:02, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> a écrit :

On 17 Dec 2015, at 15:59, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 17, 2015, at 9:51 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

if “hello” in [“hello, there”] { … }

if “hello” not in [“hello, there”] { … }

Swift is extremely sparing with keywords in operator position; the only ones I can think of off the top of my head are `is` and `as`, and even those aren’t actually operators. You’re proposing to introduce one as syntactic sugar for [array].contains(elem), and introduce an even more bizarre two-word operator for ![array].contains(elem). I don’t think that’s gonna fly.

Most programmers would probably love using them though.

If that’s the case, I’d be in the minority.

I’d rather use [“hello", “there”].contains(“hello”). That might just be my background though which is heavily object oriented.

--
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