/diesel

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactorings using macros in type position #521

Closed
killercup opened this Issue Dec 5, 2016 · 2 comments

Comments

Assignees
No one assigned
Labels
Projects
None yet
Milestone
No milestone
3 participants
@killercup @phungleson @sgrif
@killercup
Member

killercup commented Dec 5, 2016

Since Rust 1.13 we can use macros in type position (RFC #873). With those, we should be able to refactor a bunch of thing, e.g. the impls of EqAll.

@killercup killercup added good first issue help wanted labels Dec 5, 2016

@phungleson

This comment has been minimized.

Sign in to view

phungleson commented Jan 18, 2017 •
edited

Hey mate, I am trying to tackle this but it seems more complicated than I initially thought.

Do you have any other examples rather than the one in RFC #873? or any simple ideas that I can refer to, like how the macro type might look like in the case of EqAll?

@phungleson phungleson referenced this issue Feb 4, 2017

Closed

Use macro to impl EqAll for tuples #617

sgrif added a commit that referenced this issue Feb 18, 2017

@sgrif
Disallow tuples in expression positions 
Now we start to get into where this spike would affect public API. This
touches a lot of files (more than I expected, in fact) but most of the
things it touches are internal. The three methods that this actually
affects are `.select`, `.order`, and `.returning`. In all cases, the
solution is to replace `((...))` with `(hlist!(...))`.

I'm unsure if removing these impls, or the queryable impl for tuples
will be more visible. The queryable impl will almost certainly affect
our test suite more, but I'm unsure how much people are deserializing
into straight tuples in real apps. My gut says this commit will affect
more apps, but removing the queryable impl will be more painful for apps
that are affected.

The fact that this broke `create_table` in our tests is pretty funny to
me. I rely way too much on tuples.

Continuing with the theme of "this makes our code simpler", this has the
side effect of closing a few issues/PRs.

Fixes #521.
Close #617. (Sorry @phungleson, your PR looked fine FWIW)
da1fc40

sgrif added a commit that referenced this issue Feb 18, 2017

@sgrif
Disallow tuples in expression positions 
Now we start to get into where this spike would affect public API. This
touches a lot of files (more than I expected, in fact) but most of the
things it touches are internal. The three methods that this actually
affects are `.select`, `.order`, and `.returning`. In all cases, the
solution is to replace `((...))` with `(hlist!(...))`.

I'm unsure if removing these impls, or the queryable impl for tuples
will be more visible. The queryable impl will almost certainly affect
our test suite more, but I'm unsure how much people are deserializing
into straight tuples in real apps. My gut says this commit will affect
more apps, but removing the queryable impl will be more painful for apps
that are affected.

The fact that this broke `create_table` in our tests is pretty funny to
me. I rely way too much on tuples.

Continuing with the theme of "this makes our code simpler", this has the
side effect of closing a few issues/PRs.

Fixes #521.
Close #617. (Sorry @phungleson, your PR looked fine FWIW)
9c7dd52

sgrif added a commit that referenced this issue Feb 22, 2017

@sgrif
Disallow tuples in expression positions 
Now we start to get into where this spike would affect public API. This
touches a lot of files (more than I expected, in fact) but most of the
things it touches are internal. The three methods that this actually
affects are `.select`, `.order`, and `.returning`. In all cases, the
solution is to replace `((...))` with `(hlist!(...))`.

I'm unsure if removing these impls, or the queryable impl for tuples
will be more visible. The queryable impl will almost certainly affect
our test suite more, but I'm unsure how much people are deserializing
into straight tuples in real apps. My gut says this commit will affect
more apps, but removing the queryable impl will be more painful for apps
that are affected.

The fact that this broke `create_table` in our tests is pretty funny to
me. I rely way too much on tuples.

Continuing with the theme of "this makes our code simpler", this has the
side effect of closing a few issues/PRs.

Fixes #521.
Close #617. (Sorry @phungleson, your PR looked fine FWIW)
b091e8d
@sgrif

This comment has been minimized.

Sign in to view
Member

sgrif commented Jul 21, 2017

This was implemented by #617 and we didn't like the code. Variadics will eventually make this pointless anyway.

@sgrif sgrif closed this Jul 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment