Conversation
|
Gets rid of TypeTuple except for in the module name. |
|
Auto-merge toggled on |
|
Next step is to add a new module name and have the old one just use it? |
|
|
wat. |
|
This gets rid of TypeTuple which was deemed confusing because it's not really a tuple and can contain more than types. |
|
Ehem, this doesn't get rid of Also, this change isn't really documented well in the change log. It just says "changed FieldTypeTuple". I think this should either be reverted, or all |
Add legacy aliases.
Add legacy aliases. * ParameterIdentifierTuple -> *ParameterNames* (consistency with FieldNames) * ParameterStorageClassTuple -> ParameterStorageClasses * BaseClassesTuple -> BaseClasses * BaseTypeTuple -> BaseTypes * InterfacesTuple -> *BaseInterfaces* * FieldNameTuple -> FieldNames * MemberFunctionsTuple -> *MemberOverloads* (more precise) * RepresentationTypeTuple -> RepresentationTypes * TransitiveBaseTypeTuple -> TransitiveBaseTypes * isTypeTuple -> isTypes
Does the following renames in std.traits:
isExpressionTuple => isExpressions
ParameterTypeTuple => Parameters
FieldTypeTuple => Fields
ParameterDefaultValueTuple => ParameterDefaults
and in std.typetuple:
TypeTuple => Arguments
The original names are kept and documented as aliases kept for legacy compatibility. I didn't do a global search/replace in Phobos to change the names, preferring to keep this PR simple. Over time, as various modules get worked on, the names can be changed.