Stream: ideas

Topic: Consider having List.splitAt return a tuple

Francois Green (Jul 01 2024 at 13:39):

List.splitAt, nee List.split, returns a record: {before : List elem, others : List elem}. While before and others are adequate names, they may not always sum up what the split means to the rest of the program:

{before, others} = List.splitAt vampireCombatSequence 666
# vs
(preStakingEvents, postStakingEvents) = List.splitAt vampireCombatSequence 666

Plus a tuple might be less surprising to someone coming from another functional language.

Anton (Jul 01 2024 at 13:51):

One point in favor of the records is that they make it (sort of) clear what is being returned; we have functions that return {before, others} and those that return {before, after}. Clarity can help prevent bugs.

Anton (Jul 01 2024 at 13:54):

Presumably with this change, we would make it all the same for List.splitAt, List.splitFirst, List.splitLast, Str.splitFirst and Str.splitLast

Anton (Jul 01 2024 at 13:57):

A point in favor of tuples would be cleaner type signatures:

splitLast :
    List elem,
    elem
    -> Result
        (List elem, List elem)
        [NotFound]
    where elem implements Eq

Instead of:

splitLast :
    List elem,
    elem
    -> Result
        {
            before : List elem,
            after : List elem
        } [NotFound]
    where elem implements Eq

Brendan Hansknecht (Jul 01 2024 at 15:19):

I think they should all be tuples. They were just created before tuples

Brendan Hansknecht (Jul 01 2024 at 15:20):

I think knowing the first element is before is easily documentable and a common assumption

Anton (Jul 01 2024 at 15:43):

"knowing the first element is before" is indeed logical, I mainly see value in others vs after to know if it includes the split element or not.

Brendan Hansknecht (Jul 01 2024 at 15:44):

Hmmm...I never noticed that distinction consciously.

Brendan Hansknecht (Jul 01 2024 at 15:44):

I used the API some, so I must have ran into it.

Last updated: Jun 16 2026 at 16:19 UTC