Suggestions to make it easier to exclude null and undefined

[samunohito]

Hello.

I would like to suggest additional operators that will help exclude null and undefined from the sequence.

I think you'll need ritual code like filter(i => i! == null && i! == undefined) or map(i => i !!) to exclude null and undefined from the sequence.
I found a hint from Kotlin to solve this problem and used it as a reference.

• filterNotNull
• mapNotNull

I hope this proposal is meaningful to the project.

Thank you for reading.

PS:
I wrote the composition using Google Translate. Please forgive me for the dull sentences ...

[ugaya40]

@samunohito
Thank you for your prompt suggestion.
I am thinking about the criteria for adding the operator.
Please wait a moment.

PS:
I can't do anything without DeepL.

[ugaya40]

@samunohito
I thought about it.

In conclusion, I believe that these features should not be added.

The most important reason is that these features have different levels of abstraction, or more specifically, orthogonality of functionality.

Basically, we should be cautious about adding functionality to a library or framework just because it reduces the amount of description. The number of functions in a library will increase infinitely if we are not conscious of orthogonality assurance.In the case of leseq, the orthogonality guarantee is also due to the fact that it preserves TreeShaking affinity. Since we already have a means to filter data by some criteria, shouldn't we write them separately in filter and map?
(In some cases, additional functionality may be added to reduce the amount of description, in which case the amount of reduction possible should be reasonable.)
I also believe that is why many non-Kotlin environments do not opt for features like mapNotNull/filterNotNull.

This article is in Japanese, but I think it will be helpful.
https://atmarkit.itmedia.co.jp/fdotnet/chushin/roadtolinq_01/roadtolinq_01_01.html

As a side note since leseq is a library, in the case of a framework, the functionality to be added should be in line with the scenario envisioned by the framework. In the case of a library, you can add features that would degrade performance if they did not conform to the scenario, which is something that cannot be added in the case of a library. In any case, I don't think we should add features at random "just because it's useful".

I would appreciate your input.

[samunohito]

@ugaya40

Thank you for your reply.

I read the article along with your reply.
I found your opinion and the article to be absolutely correct.
Thank you for explaining why. It was very helpful.

I will withdraw this pull request.
Thank you for your time.

[ugaya40]

@samunohito

Basically

• Provide "things that cannot be achieved by combining other functions" in a way that ensures orthogonality as much as possible.

would be an additional criterion.

The exception is that it would be better to provide

• Significant performance contribution
• The meaning of the word is clear.
• The reduction in the amount of description is enormous.

would be worth providing under an alias.

Thank you very much. I appreciate your suggestions very much!