> > Though yes, I do conceed that defining these structural matches has a more > front-end one-time cost (via PR) in that you have to add loaders to various > syntax constructs in addition to potentially having to duplicate bodies > into different heads (as heads may need to be duplicated at times since you > cannot match an 'or' of structures), but that is all still only a one-time > cost to be able to define new guards that are *significantly* more powerful > than what a comparatively simple macro could do, thus allowing you to make > things like `is_struct/1`/`is_struct/2` or `is_exception/...` and others, > including for very specific internal information that a library may want to > expose a guard for that the current 1.6.0 proposal is entirely incapable of. >
While I agree it would be awesome to have an is_struct/1 guard, the correct solution to this problem is to contribute this feature upstream and allow map access in guards. So I agree your proposal does add new possibilities but that's not how we should go about implementing them, especially because of the complexity it would add to the compiler and the cost in the duplication of clauses (space and time). -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BgL%2BRUnA279KPZMsjQkMJOhXr4q6xEVGQb%3DHu5ReaQVg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
