To interface or not to interface

[Jason House]

Walter Bright Wrote:

> Jason House wrote:
> > Walter Bright Wrote:
> > 
> >> Jason House wrote:
> >>> 7. Compiler-assisted verification.
> >> For interfaces, the compile time checking is limited to verifying that
> >> functions with the right signature are supplied. Templates can go
> >> considerably beyond that with the constraint checking.
> > 
> > constraints are more powerful, but they have downsides: • If a class is
> > incorrectly defined, failure to use a type without a constraint check leads
> > to errors in the code using it instead of the class definition. Usage isn't
> > always guaranteed to be correct either, so the developer must spend extra
> > time diagnosing the real error. • If a class is incorrectly, initial usage
> > without a constraint may completely miss the error. Easy examples would be a
> > typo propogated with copy/paste, or neglecting to use save. • If a class is
> > incorrectly defined and usage uses a constraint, the developer will simply
> > get an error that there is no matching call. • If a constraint is incorrectly
> > defined and usage uses the constraint, the developer will simply get an error
> > that there is no matching call.
> > 
> > None of these scenarios are particularly helpful for a developer
> > creating/expanding a family of objects.
> 
> 
> You can also make constraints that give custom error messages, so you can do 
> better than the compiler's stab at it. How good they are is up to the designer 
> of the type.

So you're favoring an isXXX as well as a requireXXX?  Such duplication is both annoying and error prone. Making isXXX use requieXXX under the hood ishigher implementation complexity. I don't know about others, but I was drawn to its simplicity over C++. Many have praised its ability to make template programming simple. This feels like a step backwards.