<FromGitter>
<Blacksmoke16> ill have to play with it more, worst case i think we could keep functionality and just base the `raise_on_nil` on `#nilable?` of the type of the field
<FromGitter>
<Blacksmoke16> vs `field` and `field!`
<FromGitter>
<drujensen> ok. That is more crystal like. anyone have a preference?
<FromGitter>
<robacarp> I’m all for making it feel more crystalic
<FromGitter>
<Blacksmoke16> seems the invalid mem access only happens when you try to print it
<FromGitter>
<drujensen> crystalic, lol
<FromGitter>
<drujensen> @robe
<FromGitter>
<drujensen> I tried posting it several times in github. did you get them via email?
<FromGitter>
<robacarp> I did not — I have email turned off though
<FromGitter>
<robacarp> Let’s see if I got GH notifications
<FromGitter>
<robacarp> Sorry, I got a Github notification on a few threads but nothing actually shows up changed :/
<FromGitter>
<drujensen> > Regardless of which it is, how do I specify the other combination? Composition is necessary with multiple Boolean operators. ⏎ ⏎ @robacarp yes. One option which I think you documented in your comments is to be able to pass in QueryBuilder in as a parameter. This would require merging the two QueryBuilders by adding parenthesis at the correct location ⏎ ⏎ ```User.where(name: "fred").or(User.where(name:
<FromGitter>
<robacarp> Cool. I don’t think that would be hard to implement, but if that’s the case I think it makes sense for operators at a consistent scope level be associated in a simple way
<FromGitter>
<robacarp> `.where(A).or(B).where(C)` then becomes `(A or B) and C`?
<FromGitter>
<drujensen> oh
<FromGitter>
<drujensen> hhm
<FromGitter>
<drujensen> how would you do the opposite?
<FromGitter>
<drujensen> how would you control where the parenthesis go?