[Proposal] allow specifying fields in generic struct typespec

[christ...@gmail.com]

Hey all! Tiny tweak proposed for a simple feature:

Today we can use struct/0 in typespecs, which expands to

%{:__struct__ => atom(), optional(atom()) => any()}

I ran into a position today where it'd be handy to furnish the generic struct spec with fields, à la struct/1, so that you can write:

struct(foo: [atom])

which would expand into:

%{:__struct__ => atom(), :foo => [atom()], optional(atom()) => any()}

I can think of several times past when I would have used this feature; particularly within libraries that for whatever reason have macros that define new structs, all having standard fields. In those contexts it would be nice to instrument its own functions with typespecs that specify they accept *any* struct with the correct fields.

You can just write the manual %{:__struct__ => atom(), fields...} yourself today, but I assume the the point of the zero-arity built-in was to avoid the need to exposing the internal guts of a struct.

Currently none of the built-in typespec shortcuts accept arguments--they're all zero-arity. I assume historically this was to make them look more like syntax than function calls. However, now that appending parenthesis() is the norm, this effect is sort of ruined and we might as well put those parenthesis to work! I can think of other potentially useful parameterizations of the built-in typespec shortcuts but this one in particular is something I've frequently found myself wanting, rather than just inventing it for fun.

Cheers,

Chris K

[christ...@gmail.com]

Currently none of the built-in typespec shortcuts accept arguments--they're all zero-arity.

I lie, I just noticed `as_boolean/1`, so there is precedence.

[christ...@gmail.com]

I lie, I just noticed `as_boolean/1`, so there is precedence.

...and keyword/1. That's super useful, can't believe I just discovered it.

[José Valim]

It sounds good.

However, how would struct/1 be implemented? I don't think we can get such an argument and splice it into the map?

José Valim

www.plataformatec.com.br

Founder and 

Director of R&D

On Wed, Nov 1, 2017 at 12:38 AM, <christ...@gmail.com> wrote:

I lie, I just noticed `as_boolean/1`, so there is precedence.

...and keyword/1. That's super useful, can't believe I just discovered it.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6958a103-10ed-46bf-8e0c-f9c2e7fd89c4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[christ...@gmail.com]

Yeah, I ran into just that difficulty on my experimental branch a few hours ago. I didn't realize the implementation went all the ways down into erlang-lang, where we can no longer unquote_splicing! :)

I'll have to think about this more.