[RFC] do and don't

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

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

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

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

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

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

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

1 Like

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

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

5 Likes

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

3 Likes

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

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

Ohhh… I feel very silly for taking it seriously.

7 Likes

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

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.

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

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

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

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

1 Like

Same here :sweat_smile:

1 Like