RFC for concepts redesign. #167
Conversation
| ## Backward incompatibility | ||
|
|
||
| This is a backwards incompatible change but concepts are an experimental feature | ||
| which does not hold stability guarantees (even as of the upcoming v1.0). |
There was a problem hiding this comment.
According to @Araq on IRC they do. (except for do)
There was a problem hiding this comment.
Link? Everything that's in experimental has no stability guarantees, we wrote this in the release notes.
There was a problem hiding this comment.
There was a problem hiding this comment.
Not that I necessarily agree that all experimental features should have stability guarantees..
There was a problem hiding this comment.
Er, to clarify, what I meant was these features won't be removed, but overhauled. 'do' is an exception, we can simply remove it, without loss of functionality.
There was a problem hiding this comment.
That's not true at all as far as our promise in the release notes goes. You shouldn't be making extra promises in such contexts, as far as the promise we made on nim-lang.org any experimental feature can be removed or replaced by another feature.
|
|
||
| The downsides to this proposal are that what can be specified is diminished, | ||
| that said I don't believe this is significant and I go through examples of this | ||
| below. |
There was a problem hiding this comment.
This RFC should not remove the "old" concepts, IMO.
There was a problem hiding this comment.
Not immediately, but eventually it should.
|
|
||
| The current concepts syntax is difficult to grok as it requires mentally | ||
| evaluating Nim code. The concepts implementation is also currently very buggy | ||
| and would require significant effort to make reliable. |
There was a problem hiding this comment.
Probably a similar effort required to make the concepts this RFC proposes reliable. In fact most if not all cases these new concepts cover are reliable with the current concepts.
dom96
force-pushed
the
concepts-proposal
branch
from
f429535 to
32fe28f
Compare
dom96
force-pushed
the
concepts-proposal
branch
from
32fe28f to
89884f2
Compare
|
I feel like a broken record by now, but all my points from the previous discussion apply here as well: Point 1 (that concepts must be able to require associated types and constants) is especially important. Any design that doesn't cover this aspect is just not workable. In general, the type requirements in generic programming are often fuzzier than the typical OOP interface and I don't see a particularly good reason to limit the expressive power of the language, only to satisfy some superficial syntax preferences. If you think that the current implementation issues of concepts are caused by their syntax, you are deeply mistaken. |
|
Also, concepts are now finally standardised in C++. Is anyone of the opponents of the current syntax familiar with the C++ spec? Our current design is pretty close to C++'s way of doing things and soon millions of developers will be trained to understand this syntax. I wonder if anyone would have ever complained if you were first trained in your university to understand what a concept definition is (in C++). |
|
@zah I have referred to your comment explicitly in my document and have responded to it. I did my best to show what a Serializable concept would look like with this syntax, for the other examples I need more information as I didn't really understand their purpose. As far as the syntax goes, I think my argument around it is far from superficial, the fact that concepts currently require evaluating the concept body (both by the compiler and by a human in their head) is a big downside. But if that really doesn't create implementation problems then I think we should at least instead provide the syntax I propose on top of the current concepts via a macro or otherwise. |
|
But this type
Serializable = concept
iterator fields(x: Serializable): RootObj
proc serialize(f: Serializable, s: Stream)doesn't make sense. |
|
Superseeded by my RFC. |
This has been a long time coming. Refs #13.