[RFC] do and don't

Crystal Contrib
1

What do you think about being able to use don't in addition to do in blocks?

For example:

numbers = 1..5

numbers.select do |num|
  num.even?
end # => [2, 4]

numbers.select don't |num|
  num.even?
end # => [1, 3, 5]

In that way we could deprecate, and eventually remove, Enumerable#reject. We don’t want aliases in the language, so that would move us closer to that goal.

Of course this could be applied to any method that receives a block.

Thoughts?

16 Likes
2

yup! Love it. Already working on porting all of the Lucky code over.

Oh, and to add to this, it’ll make these lines of code easier to use

2 Likes
3

I don’t understand how it would work for blocks that don’t return Bool. For example, how would #map work?

numbers = 1..5

numbers.map don't |num|
  "*" * num
end # => ???
1 Like
4

It could even be composed with another proposal I had in mind:

A do!, and potentially don't! could emit code that can be executed in parallel. No need to wait for one iteration to launch the next one. This is not the same as spawning in each iteration. This could adapt however is needed to run the body in parallel, not just concurrently, and maybe with SIMD instructions one day.

WDYT?

4 Likes
5

I don’t have any good reason for this, but I would strongly prefer dont over don't. To have the apostrophe in don't would bother me more than what it would it be worth to me to keep it proper English. I see the apostrophe as an operator outside of a string (you also wouldn’t use one as part of a variable’s name).

That’s just my opinion, but maybe others feel similar.

EDIT: Would there be also a one-liner version of it? I mean like select{|foo| foo.bar}

7 Likes
6

We could also add a doh! keyword for rescuing exceptions while enumerating over collections:

strings.map { |s| s.to_i } doh! { |value,error| 0 }
11 Likes
7

Same as @anon69898395 , I vote for dont instead of don't

1 Like
8

Deciding between dont and don't could confuse new users. I suggest do_not in it’s edible sandwich form: donut

flavors.select donut |flavor|
  flavor.excludes?("bacon") || flavor.excludes?("ketsup")
end
2 Likes
9

Let’s do Yoda-style with do or doNot … there is noTry.
starwarsday

5 Likes
10

Is this some April fools joke, but one day late ?

3 Likes
11

The original post was written on April 1. At least it was that day in Argentina where the author lives. If you’re further east, Discourse might show a different date based on your UTC offset.

However, if you’re looking for an April fool’s, you might want to use this instead: April First joke - Programming language designers unite! - YouTube

5 Likes
12

Yes, it was 7pm on April 1st on my time. I didn’t think about doing an April 1st this year, but this silly idea arrived late in the day :person_shrugging:

8 Likes
13

Ohhh… I feel very silly for taking it seriously.

7 Likes
14

It would explain everything since I’m in France. Good one anyway !

15

Hm, that’s odd though. Observed time in (metropolitan) France should be 2022-04-01 23:36 CEST (UTC+2). At least that’s what I’m shown in that same time zone.

16

Well, for me it says “2022-04-02 12:36” and my configured timezone is Europe/Paris.

17

All right, something is off here. It seems I get the wrong time display.

18

Yeah, my previous comment shows as being posted 1 minute ago at 11:13, but it’s actually 12:13 now.
I observe the same wrong offset in another browser. But I get the correct time on a different machine. So it seems to be my local setup. Perhaps it’s related to the fact that I haven’t restarted the system and browser since the daylight savings switch two weeks ago :person_shrugging:

EDIT: Yep, my browser thinks it’s still CET (UTC+1) instead of CEST (UTC+2) :man_facepalming:

1 Like
19

Don’t feel bad. It was bad timing. And I also fell to a couple of April first jokes.

1 Like
20

Same here :sweat_smile:

1 Like