Ensure DispatchedSet unique keys on construction

[charleskawczynski]

This PR changes the behavior so that we error on the construction of DispatchedSets, rather than throwing an error on getindex(::DispatchedSet, key) for non-unique keys. I think I prefer this behavior, erroring on construction.

At first I tried using unique_elems, but this incurred runtime overhead. Then, I tried the generated function elems_are_unique, and that seems to keep things all at compile time 🚀!

I think it's still useful for users to have unique_elems / unique_keys(dt::AbstractDispatchedTuple), in case they may want to convert a DispatchedTuple into a DispatchedSet. I'll avoid exporting for now so that we can bikeshed the name / design.

[codecov]

Codecov Report

Merging #23 (87a36fb) into main (b8457c3) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #23   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         1           
  Lines           63        78   +15     
=========================================
+ Hits            63        78   +15     

Impacted Files	Coverage Δ
src/DispatchedTuples.jl	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b8457c3...87a36fb. Read the comment docs.

[ali-ramadhan]

It seems like using unique_elems in construction or getindex has performance implication but wouldn't it be a one-time cost in the constructor and a cost every call if it's in getindex?

[charleskawczynski]

It seems like using unique_elems in construction or getindex has performance implication but wouldn't it be a one-time cost ...?

Yes, unless it's repeatedly constructed.

and a cost every call if it's in getindex?

I think the getindex cost is purely compile-time.

[charleskawczynski]

After experimenting, I'm going to leave things as they were but still introduce unique_elems / unique_keys(dt::AbstractDispatchedTuple).

[charleskawczynski]

After further experimentation, I think we can get back to basically no runtime overhead using generated functions 😬.

[ali-ramadhan]

@generated is basically black magic to me lol

[charleskawczynski]

@generated is basically black magic to me lol

I'm not sure I have the best understanding, but, my mental model consists of three fundamental pieces:

1. @generated always return expressions
2. @generated is an escape hatch where you can generate code only when you know information about variable types, but not values. So, AFAICT, generated function signature arguments might as well be foo(::TA, ::TB, ...) instead of foo(a::TA, b::TB, ...), because there is no a & b at the time that the generated function is first called (and the code is generated).
3. @generated can be a burden on the compiler

[charleskawczynski]

I'm happy with these changes overall.

[charleskawczynski]

bors r+

[bors]

Build succeeded:

• ci 1.5.2 - macOS-latest
• ci 1.5.2 - ubuntu-latest
• ci 1.5.2 - windows-latest
• docbuild