Closed hamidb80 closed 1 year ago
I'm not sure the complexity here is worth the possible benefit. Why not just use sensible names for types and variables? With types you can even use type aliases:
type Path = string
proc join(left, right: Path): Path
My first reaction is: That's what (doc) comments are for. What benefit does this have over writing a comment that explains what the table stores or what the proc returns? IDEs can also show the doc comments, so you don't have to open the documentation separately. Sure, there are people not documenting their code, but I doubt that providing new syntax for documenting code would change that.
Thanks for your comments, I'm convinced that it's not necessary.
btw I implmented !
macro to achieve similar to what I've proposed:
macro `!`(namedTuple): untyped =
expectKind namedTuple, nnkTupleConstr
expectLen namedTuple, 1
namedTuple[0][1]
now this is possible:
Table[!(name: string), !(isReady: bool)]
thanks to the macro system :D
Abstract
Labeling types enables you to write more self-document code, both easy for you to review in the future and for other people to get the idea behind your algorithm.
it is specially good for
proc
s that do many jobs; as it is not much obvious what they are returning as result.Motivation
scenario 1
assume you're reading someone's code, you came upon something like this:
wow! what is it? is that a table for (
ownerName
->isCrushed
) or (carName
->hasWheels
) ??scenario 2
you wanna develop a telegram bot using telebot for example, you came upon
UpdateCallback
type:what is
Future[bool]
for? why abool
? you can't even guess it without reading the docs [RTFM right? :D]Description
but if you could somehow just label your types, the code would be a lot more readable!
Code Examples
scenario 1
scenario 2
Backwards Compatibility
the syntax
(label: Type)
definitely has conflicts with one-field-tuples:other syntaxes that I can think of: