I don't think it is a good idea to be explicit about `<` being a proc. For me
concepts are about (static) duck typing: if it supports `<`, then it satisfies
the concept. This is good, because I will want to call `<` on members of the
type. I see concepts as a promise that the code I write next
I don't think my proposal is just about the syntax, the underlying semantics
change significantly. As I've mentioned, the specification becomes more
concrete and less prone to surprises, i.e. _semantically_ concepts become
simpler.
@cdunn2001 I just replied to your other thread about concepts. I'm not seeing
the issue you were mentioning.
[https://forum.nim-lang.org/t/2999#25214](https://forum.nim-lang.org/t/2999#25214)
@arnetheduck, regarding run-time polymorphism, there is a planned feature
called "VTable types". You can read the spec here:
@cdome, there is simple way to ensure that your type conforms to a concept.
After defining the type and all its procs, put a static assert near the end of
the module:
static:
assert Foo is SomeConcept
Run
Future versions of Nim will produce a nice error message
The concept syntax has been discussed already ad nauseam. The current syntax is
inspired by the ConceptsLite proposal that will eventually make its way into
C++, so in a distant future it should be familiar to a lot of people.
Considering that the concept definitions will be roughly 0.0005% of
Well but we can tweak the semantics endlessly to make it fit ever more varying
concept descriptions we might want to write, but we will be stuck with the
syntax. It's not foolish to strive for a good syntax.
The problem with `concept` is that it doesn't work with `seq[C]`. If you're not
aware of that, you can spend a huge amount of time debugging. After you're
aware, you have to modify your API in potentially difficult ways.
Other than that, I think they're awesome. Not kidding. I love the syntax.
IMO, Concept syntax is great from the user perspective. It clearly describes
what concept can do. From the implementer pointer of view it look like it is
far too easy to miss concept requirement and you are not sure while writing the
code you are matching the concept or not.
I don't think what
Agreed with GULPF: the imperative syntax of concepts makes it more suited to
some kind of duck typing. Moreover, I find
type
Comparable = concept x, y
(x < y) is bool
Run
simpler than
type
Comparable[T] = concept
proc `<`(x,
IMO there are good reasons for the current syntax. What if < is implemented
with a template? What if it has a third argument with a default value? What if
only `<`(x, y: int): bool` exists, but there's a converter for `T` -> `int`?
Since Nim has so much flexibility in how to implement things,
Personally I would prefer to simplify the concept syntax.
>From the current syntax:
type
Comparable = concept x, y
(x < y) is bool
Run
To something like:
type
Comparable[T] = concept
proc `<`(x, y: T): bool
Run
I'm looking at an issue that proposes using concepts to enforce a simple
interface -
[https://github.com/status-im/nim-eth-common/issues/8](https://github.com/status-im/nim-eth-common/issues/8)
\- and find myself thinking that the syntax is very odd; an interface is
declared up-front to be
13 matches
Mail list logo
