std.experimental.checkedint is ready for comments!

[Walter Bright via Digitalmars-d]

On 6/14/2016 9:48 PM, tsbockman wrote:
> On Wednesday, 15 June 2016 at 03:42:52 UTC, Walter Bright wrote:
>> On 6/14/2016 8:15 PM, tsbockman wrote:
>>> Do I really need to give it some giant multi-word name?
>>
>> Something better than 'N'.
>
> `Int`? `Base`?

'Integer' would work fine.


> Whatever it is needs to be short; `BaseIntegralType` is *way* too long for this
> and would make many of the signatures painfully verbose.

Since they aren't recursive, that shouldn't be a problem. Besides, the signature 
will be the actual type name, not the alias for it.


>>> Besides which, Phobos uses single-letter names for template parameter type names
>>> all over the place.
>> Generally 'T' is used for 'any type'. 'N' has no corresponding significance.
> I have seen all of `S`, `F`, `G`, `X`, `R`, `C`, `A`, and `B` used as template
> parameter names in Phobos. Often there is no particular significance to the
> letter chosen, but the purpose of the parameter is obvious from the context,
> anyway.

1. Each one should be evaluated on its own merits.
2. Style is not something cast in stone, we try to constant evolve better ways.
3. Bad practice in one case is not a rationale to use bad practice elsewhere :-)
4. You mentioned greppability - 'N' is as ungreppable as it gets!


> Using short template parameter names helps keep D's already-very-long signatures
> from growing even longer than they already are.

The parameter names don't appear in the signature.


>> Greppability is inddeed a plus, but 'bscal' is needlessly uninformative. Note
>> that publicly facing names should not be so.
> `basic`? `base`?

'integer'? (to go with 'Integer' for the type)


> Again, this needs to be short for readability and usability. Normally it's not
> needed at all, but when it is needed (like in the implementation of `SmartInt`
> and `SafeInt`), it tends to be needed *a lot*.

Internal to the implementation does not require it to be short.


>> I see no love for output ranges :-(
> I will add support.

Thank you.