-
-
Notifications
You must be signed in to change notification settings - Fork 421
Templated TypeInfo #3174
base: master
Are you sure you want to change the base?
Templated TypeInfo #3174
Conversation
Thanks for your pull request, @andralex! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + druntime#3174" |
I took upon painting the bikeshed by changing the name from
|
__ is reserved for compiler internals like auto-generated variables. For runtime template hooks we typically use |
Wouldn't this be okay for the same reason as |
Added statically-typed versions of all functions, so if people write |
Mind the 32bit platforms. |
Per discussions with @WalterBright, it turns out it's not reasonably feasible to do an incremental replacement. The plan instead is to develop Currently no support for |
… it in read-only memory
{ | ||
return __typeid!U1.argTypes(arg1, arg2); | ||
} | ||
else static if (__traits(isStaticArray, T) || __traits(isAssociativeArray, T)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, is expression should be able to match static array, and associative arrays as well, for example:
is(T : U[size], U, size_t size) || is(T : K[V], K, V)
assert(p); | ||
p.__postblit(); | ||
} | ||
else static if (__traits(isStaticArray, T) && is(typeof(&UnqualifiedType.init[0].__postblit))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may trip on static arrays with 0 length (although they don't make much sense, they are allowed in D right now). An alternative would be to extract next type from static array using is expression, and use it's init value: is(T : V[size], V, size_t size) && is(typeof(V.init.__postblit))
assert(p); | ||
p.__dtor(); | ||
} | ||
else static if (__traits(isStaticArray, T) && is(typeof(&UnqualifiedType.init[0].__dtor))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same issue with 0 sized static array.
return 1; | ||
} | ||
|
||
static string toString() @nogc nothrow pure @safe { return T.stringof; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to [https://dlang.org/spec/property.html#stringof](Properties page) stringof returns just name of Type, not fully qualified name of Type, therefore if there are two Dog classes one in test module and another in impl module both would be printed as just Dog (hence no way to differentiate between test and impl Dogs). It is also different from what toString for original TypeInfo is returning, which is fully qualified name. Something as fullyQualifiedName from std.traits should be implemented, although, to note, fullyQualifiedName is still not compliant with toString from TypeInfo, since it has tendency to shorten eponymous templates, while TypeInfo doesn't, in other words TypeInfo.toString for Dog!int would return smth like: "Dog!int.Dog" while fullyQualifiedName from std.traits would return just: "Dog!int"
return T.sizeof; | ||
} | ||
|
||
alias tsize = tsizeImpl; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it is better to rename tsizeImpl
to tsize
?
assert(sa1[] !is sa2[]); | ||
|
||
ti = __typeid!(S[3]); | ||
assert(ti.getHash(&sa1) == ti.getHash(&sa2)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice coverage tests
} | ||
return (d1 == d2) ? 0 : ((d1 < d2) ? -1 : 1); | ||
return result; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this refactoring objectively better? If it isn't, I find it significantly more difficult to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's supposed to be faster
Starting small. This duplicates the implementation in https://github.com/dlang/druntime/blob/master/src/rt/typeinfo/ti_int.d. The idea is, of course, that the templated implementation will replace implementations for all scalar types. For testing purposes I restricted it to int.
The thing works if
typeid(int)
lowers toRTTypeid!(int)
. The use of eponymous templates elegantly hides the type name.