Just in case I didn't make that clear enough: _explicit_ and _satisfies_ would be **optional**, I don't want to restrict concepts ore take anything away from them in any way.
> Concepts in C++ was designed to be used without explicitly stating the > interface. I thing golang interfaces work the same way. Exactly, and interfaces **were** designed in other languages to be explicitly implemented, but the golang people don't give a damn about that, so maybe we can take some liberties, too . But seriously, if "explicit concept" really is a bad name, one could look at it as "interface on steroids" and invent a better one. @Araq: Making as much author intention as possible checkable by the compiler is seen as a good thing by many people. Since you don't seem to think it's important with concepts, I won't waste people's time with a lengthy discussion. Would you be ok with macro packages in the standard lib implementing structural language extensions like "explicit concept", "class" or "interface"? I understand the "We keep the language core lean and mean, implement the high level stuff you need with meta-programming" approach, but I'm afraid that will keep tons of people away from Nim if they don't get semi-official default implementations of useful things they already know.
