Traits modules partitioning

[ljmf00]

I came with this partitioning from the standard library. What do you think?

taurus.traits.symbols - Symbol Name traits
taurus.traits.functions - Function traits
taurus.traits.aggregation - Aggregate Type traits
taurus.traits.conv - Type Conversion
taurus.traits.of - SomethingTypeOf
taurus.traits.uda - User-Defined Attributes traits
taurus.traits.selection - Selection traits
taurus.traits.mangle - Mangle

I still don't know where to insert General Types, Type behaviours and Categories of types section of phobos here.

[ljmf00]

@iK4tsu

[iK4tsu]

• Type behaviours - qualifiers
• Categories of types - signature / classification
• General types - common / regular / recurrent / general

[iK4tsu]

How about meta traits? Should they be considered here? And what about traits used some other modules, such as std.range traits or std.math floatTraits? For now I'm using an internal.d file to implement these exceptions inside the module itself.

[ljmf00]

• Type behaviours - qualifiers
• Categories of types - signature / classification

Can you elaborate on those words, whats the exact meaning on this context?

• General types - common / regular / recurrent / general

I would go with common, what do you think?

How about meta traits? Should they be considered here? And what about traits used some other modules, such as std.range traits or std.math floatTraits? For now I'm using an internal.d file to implement these exceptions inside the module itself.

What kind of traits are there? Can you give an example?

[iK4tsu]

Can you elaborate on those words, whats the exact meaning on this context?

Type behaviours are traits which give feedback on whether a type can do something or not (isCallable, isDelegate, isIterable, ...). They don't refer to the type itself but instead to the qualifications of that type. Is this type callable, or iterable, etc, are qualifications of certaint types.

Categories of types are traits which refer to the type itself. They check whether a type is something (isType,
isArray, isPointer, isSomeChar, ...). These are traits which return true or false based on type itself, the category of it, or, in other words, it's classification or identity.

I would go with common, what do you think?

Well I suggested it so I'm ok with that.

What kind of traits are there? Can you give an example?

std.range: isInputRange, isOutputRange, ...
std.math: floatTraits (no in docs but available: https://github.com/dlang/phobos/blob/master/std/math.d#L10019)
std.meta: not really traits, but alias sequences, however allSatisfy, staticIndexOf, and things like that are considered traits
There may be other modules with traits.

This is because of one thing only. If we're going to, in the future, implement additional traits, how will we differ a trait from taurus.traits from a trait of a module? Imagine you want to add a traits which aplies only to the future Optional, not talking about traits like isOptional. Will we implement such trait within the module itself, or in taurus.traits? What would be the rules to say this belongs here and that doesn't?

[ljmf00]

Type behaviours are traits which give feedback on whether a type can do something or not (isCallable, isDelegate, isIterable, ...). They don't refer to the type itself but instead to the qualifications of that type. Is this type callable, or iterable, etc, are qualifications of certaint types.

The problem with the qualifiers name is that you are defining qualifiers as another thing. In D and other languages qualifiers have a strong meaning and they are explicitly defined in the spec. See also qualifiers in C, for example, here. We can definitely have a section just for type qualifiers, but isCallable, isDelegate, isIterable, ... are not type qualifiers.

Categories of types are traits which refer to the type itself. They check whether a type is something (isType,
isArray, isPointer, isSomeChar, ...). These are traits which return true or false based on type itself, the category of it, or, in other words, it's classification or identity.

signature can be misleading with signatures related to the ABI, even though there's nothing to do with traits. I would like classification if the word were not that long. The best synonym I find for classification is kind, but it could be weird, idk.

std.range: isInputRange, isOutputRange, ...

Sure, we can have a module for that in traits.

std.math: floatTraits (no in docs but available: https://github.com/dlang/phobos/blob/master/std/math.d#L10019)

Those are not traits. Traits are related to types and symbols, not with constant values. They are not documented because they are used internally, marked as package.

std.meta: not really traits, but alias sequences, however allSatisfy, staticIndexOf, and things like that are considered traits

Those "traits" are all about a sequence of types. Some of them, like you mentioned could be merged into taurus.traits. but we need to come up with a different section for that.

There may be other modules with traits.

Yeah, I understand now. The ranges traits could be definitely on a traits module separately, although,...

This is because of one thing only. If we're going to, in the future, implement additional traits, how will we differ a trait from taurus.traits from a trait of a module? Imagine you want to add a traits which aplies only to the future Optional, not talking about traits like isOptional. Will we implement such trait within the module itself, or in taurus.traits? What would be the rules to say this belongs here and that doesn't?

... yeah, we should come up with a "standard" for that.

[ljmf00]

Missclick :(

[iK4tsu]

One thing we could do is to expand the std.traits meaning. Phobos's module is all about traits "which extract information about types and symbols at compile time". By expanding I mean separating these traits from each other with modules. The big group of traits would be in types&symbols module and then we could have meta module, range module, algorithm module, etc, to specify traits specific to such modules. By having this we could have taurus.meta with all the alias sequences implementations, like AliasSeq and aliasSeqOf, etc, and it's traits would be implemented along the other traits but within taurus.traits.meta. Another positive thing about this is that it would help distribute and distinguish what is what and would make finding some specific trait easier. Personally, I would always forget some traits were in fact std.meta traits and I've found myself many times looking for some in the std.traits module.

[ljmf00]

One thing we could do is to expand the std.traits meaning. Phobos's module is all about traits "which extract information about types and symbols at compile time". By expanding I mean separating these traits from each other with modules. The big group of traits would be in types&symbols module and then we could have meta module, range module, algorithm module, etc, to specify traits specific to such modules. By having this we could have taurus.meta with all the alias sequences implementations, like AliasSeq and aliasSeqOf, etc, and it's traits would be implemented along the other traits but within taurus.traits.meta. Another positive thing about this is that it would help distribute and distinguish what is what and would make finding some specific trait easier. Personally, I would always forget some traits were in fact std.meta traits and I've found myself many times looking for some in the std.traits module.

I agree, I guess some std.meta traits could be merged into std.traits in some way. I'm not sure what std.meta means, but I assume it's all about metaprogramming and that's too generic.

This is what D considers metaprogramming. I agree although, std.meta could be renamed. I guess we need to change that name to a more pleasant name, like taurus.traits.seq or taurus.traits.sequence ?

[iK4tsu]

It's better if we keep meta as it's well established as an std module within Phobos, meaning people are used to the name and it's content. Calling it sequence makes it sound to generic when it's only about template sequences (aka alias sequences).

[ljmf00]

It's better if we keep meta as it's well established as an std module within Phobos, meaning people are used to the name and it's content. Calling it sequence makes it sound to generic when it's only about template sequences (aka alias sequences).

Then I would prefer to keep in the same module, like taurus.meta. The advantage I see putting meta in traits is to be more specific in the naming.

[iK4tsu]

But that's the difference, std.meta has meta implementations and brings traits along, just like std.range. We would still keep the meta meaning but split into two, the actual meta functions in taurus.meta and it's traits in taurus.traits.meta.

[ljmf00]

But that's the difference, std.meta has meta implementations and brings traits along, just like std.range. We would still keep the meta meaning but split into two, the actual meta functions in taurus.meta and it's traits in taurus.traits.meta.

Humm, ok. Got your point. Then, what do you consider to be traits on std.meta ? Because I don't a real distiguishable difference. We can come up with a definition.

[iK4tsu]

I consider allSatisfy and anySatisfy meta traits.

[ljmf00]

I consider allSatisfy and anySatisfy meta traits.

Sure.

To summarize, we have:

taurus.traits.symbols - Symbol Name traits
taurus.traits.functions - Function traits
taurus.traits.aggregation - Aggregate Type traits
taurus.traits.conv - Type Conversion
taurus.traits.of - SomethingTypeOf
taurus.traits.uda - User-Defined Attributes traits
taurus.traits.selection - Selection traits
taurus.traits.mangle - Mangle
taurus.traits.qualifiers - Type qualifiers traits
taurus.traits.common - General types traits
taurus.traits.meta - taurus.meta related traits
taurus.traits.range - Ranges related traits
taurus.traits.behaviour - Type behaviours
taurus.traits.classification - Categories of types

The only one I'm septical is the last one. Unless we don't have a name for it.

[iK4tsu]

I guess the last can just be categories. And from what we talked above I suggest adding types or typesymbols before each module. This splits the current group of std.traits with the new ones.

• taurus.traits.types.*
• taurus.traits.range.*
• taurus.traits.meta.*
• ...

[iK4tsu]

This if you want to follow the current each module in it's separated file rule. Otherwise taurus.traits.types would be split into various traits and the others, if smaller, as taurus.traits.meta would be modules themselves.

[ljmf00]

I guess the last can just be categories.

Well, sure. If we have a better name, we could change it before the first release.

And from what we talked above I suggest adding types or typesymbols before each module. This splits the current group of std.traits with the new ones.

• taurus.traits.types.*
• taurus.traits.range.*
• taurus.traits.meta.*
• ...

I'm against having .types on traits. Traits are all about types and I think this is just redundant and makes every module longer unnecessarily. Even meta and range traits are all about types.

Also as quoted:

Templates which extract information about types and symbols at compile time.

[iK4tsu]

Sure, agreed.