-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TODO] Nim should allow nested types #7449
Comments
What's wrong with? type
Bar = object
name*: string
Foo* = object
age*: int
bar*: Bar
var a:Foo
var b:Foo.bar Notice that Bar is not exported but its fields are (or you can use "accessors" procs) Now there might be some need on the importcpp side but for pure Nim I think my solution is fine. |
TIL you can declare a variable's type using the field of another type. Nice. |
|
@timotheecour you are totally right
But you would be required to resolve conflicting names manually when wrapping libraries. In this example I did it with prefixing the partent type to the subtype. Then your example with generics, I am afraid I could not get it to work with a template like the template above. But luckyly in practice that is rarely a problem
FooBar is not a subtype here. But it solves the same purpose as the subtype, just with less nesting involved. Sometimes you just need to think a little bit different when learning a new language, not everything can be mapped 1:1. Especially subtypes. |
I am not sure I understand - doesn't your protobuf example embed Bar inside Foo (hence increases Foo's size)? In any case, I would not introduce such a breaking change at this point, given that its advantages are somewhat limited |
Regarding creating type associations involving generic types, the following should work: import typetraits
type
Foo[T] = object
Bar[T] = object
Baz[T, U] = object
BazAlias[T] = Baz[int, T]
template matchingBar[T](f: type Foo[T]): typedesc = Bar[T]
template unboundBaz(f: type Foo): typedesc = Baz
template partiallyBoundBaz[T](f: type Foo[T]): typedesc = BazAlias[T]
var
x1: Foo[int].matchingBar
x2: Foo[string].unboundBaz[float]
x3: Foo[float].partiallyBoundBaz
echo x1.type.name
echo x2.type.name
echo x3.type.name The expected output should be:
I consider it a bug that it's currently failing. There is an issue with resolving bound types names inside template bodies. |
@zah well you did not properly handle the nested type with the generic. Each instance of |
Not gonna happen anytime soon, sorry. We need to focus on stability, not on more features, no matter how good they might look. |
(if nested types are already supported, sorry about the noise and please let me know how!)
rationale
no nested types makes wrapping libraries in other languages problematic
eg:
test.cpp:
which gives invalid Nim file.
These name clashes are unavoidable in large C++ libraries (or other languages), and workarounds seem very costly (eg changing C++ code? custom handling in nim wrapper?)
other problematic example
no nested types makes using DSL's problematic, eg protocol buffers:
https://github.com/PMunch/protobuf-nim generates types Foo, Foobar (for submessage) and FooBar (top-level), which clashes and produces invalid code.
NOTE: these protobufs could be from external third party libraries over which we have no control
Proposed syntax for nested types in Nim:
The text was updated successfully, but these errors were encountered: