ComparisonTechniques

Allow T == Option[T] comparison *

Forbid T == Option[T] comparison *

Type-check two trees, if one of them has optionals, go into the optionals to find the root types in each of them. Then compare the types that are inside. If they are not compareable, abort the build. Otherwise return type of which side (or both) has the optional. In order to do the actual comparison, the 'weak conformance' operator is used and a subclass is allowed on either side of the ==. Weak conformance is necessary so that Longs can be compared to Ints etc...

(not used yet but will be used when support for 'extras' dsl functionality is added) Do equality checking on the database level with the ansi-style truth table (i.e. always false if one side is null)

Taken from the identically named method in Parser.scala in Scala2-Quill. Much of this logic is not macro specific so a good deal of it can be refactored out into the quill-sql-portable module. Do equality checking on the database level with the same truth-table as idiomatic scala

Match types in the most wide way possible. This function is not for generalized type equality since quill does not directly compare anything, rather it just translates things into SQL expressions. This kind of check is used in a general sense when things that it doesn't even make sense to compare are compared e.g. an Person and a String. In this case, we want to provide some kind of compile-time warning that the comparision the user is attempting to do in SQL is non sensical in the first place. Therefore when there is any kind of possibility that the expression makes sense (e.g. by comparing a Dog to a Animal (i.e. class to subclass), by comparing two numeric types of any kind etc... we allow the comparison to happen). For int/long/float/double comparisons don't crash on compile-time typing can re-evaluate this upon user feedback