Why mem.eql rather than mem.equal?

Help
1

Given that Zig usually prefers full names for functions (putAssumeCapacityNoClobber) I am curious why did we end up with eql as a standard name? Is this just a historical accident lost in the mist of time, or is there some specific naming conflict why equal won’t work?

(I understand that stdlib names are not at idiomatic now, because we have not reached the stage where combing through stdlib makes sense)

1 Like
2

Good point! I agree that the better and more common convention for the stdlib code seems to be using full names, so the only short names remaining in stdlib should probably be the ones containing keyword names, like struct and enum. As for the reason behind mem.eql (meta.eql as well), those were some of the very first functions to appear in stdlib because of their heavy use in the compiler code, which has the opposite to stdlib convention of going for shorter names.

1 Like
3

I think that’s what this is. I don’t recall anything interesting specific to eql since the time I joined.

One thing to note is that the other function you mention has to communicate more complexity to the user than eql which is big part of why it’s more descriptive. I can imagine a version of eql that asserts same length for both arguments (instead of branching on it) being called eqlSameLen.

And related to that we also have .len instead of .length, which presumably relates to how frequently it’s meant to be used. I imagine that eql was shortened for the same reason.

At some point we did have a community member who gave a talk on coding by voice (because of wrist pain) who mentioned that having abbreviations is really bad for that use case and that we should prefer proprely spelled names. Maybe that influenced subsequent decisions by the people who designed those apis (although I think that abbreviations and descriptive names are somewhat separate things).

This is the talk I’m referring to:

3 Likes
4

And related to that we also have .len instead of .length,…

@kristoff I guess it makes sense for .len to exist since it’s defined in the compiler for slices, arrays and whatnot.

However, it’s interesting, because this brings me to a thought that, perhaps, it’s better for mem.eql to be a compiler builtin, taking into account how often it is used. The obvious name would be @memeql, which would nicely complement the existing @memcpy and @memset. In addition, it would take only two arguments just like @memcpy except without the noalias requirement.

While the less frequently used meta.eql can become just full name equal, which would match other declarations that use that full name like the testing.expectEqual... functions.

1 Like
5

my point is not about it being in the stdlib vs in the language, but rather that len is an abbreviation of length, similarly to how eql is an abbreviation of equal

6

I see :slightly_smiling_face:
I was just thinking in terms of established stdlib and compiler internals (including builtins) naming conventions, with the former using full names and the latter going for shorter ones.

7

I always thought there may have been a Lisp vibe here… eq vs eql vs equal and all… :slight_smile:

8

Reminder that audit the standard library API and implementations · Issue #1629 · ziglang/zig · GitHub will be apocalyptic breakage. Consistent naming conventions is part of it. In fact there’s a comment on that issue mentioning eql specifically.

6 Likes