mixin template's alias parameter ... ignored ?

[someone]

On Monday, 12 July 2021 at 05:33:22 UTC, ag0aep6g wrote:

> Bug: You mixed up `wstring` and `dstring`. `wstring` is UTF-16. 
> `dstring` is UTF-32.

I can't believe this one ... these lines were introduced almost a 
week ago LoL !

> Style: `typeStringUTF` is a type, so it should start with a 
> capital letter (`TypeStringUTF`).

Style is a personal preference; I am not following D style 
conventions (if any) nor do I follow any other language style 
conventions; I have my personal style and I apply it everywhere, 
I think it is not important which style you use, what is 
important in the end is that you adhere to your chosen style all 
the time -unless, of course, you are contributing to x project 
which states its own style and then there's no choice but to 
follow it.

>> private size_t pintSequenceCount = cast(size_t) 0;
>> private size_t pintSequenceCurrent = cast(size_t) 0;

> Style: There's no need for the casts (throughout).

I know. I do these primarily because of muscle memory and 
secondly because I try to write code thinking someone not knowing 
the language details may be porting it later so I tend to state 
the obvious; besides, it won't hurt, and it helps me in many ways.

>> @safe public typeStringUTF encode() {
>> 
>>        scope typeStringUTF lstrSequence = null;
> [...]
>>        return lstrSequence;
>> 
>>     }
>
> Bug: `scope` makes no sense if you want to return 
> `lstrSequence` (throughout).

Teach me please: if I declare a variable right after the function 
declaration like this one ... ain't scope its default visibility 
? I understand (not quite sure whether correct or not right now) 
that everything you declare without explicitly stating its 
visibility (public/private/whatever) becomes scope ie: what in 
many languages are called a local variable. What actually is the 
visibility of lstrSequence without my scope declaration ?

>> @safe public typeStringUTF toUTFtake(
>>    scope const size_t lintStart,
>>    scope const size_t lintCount = cast(size_t) 1
>>    ) {

> Style: `scope` does nothing on `size_t` parameters (throughout).

A week ago I was using [in] almost everywhere for parameters, 
ain't [in] an alias for [scope const] ? Did I get it wrong ? I'm 
not talking style here, I'm talking unexpected (to me) 
functionality.

>> scope size_t lintRange1 = lintStart - cast(size_t) 1;
>> scope size_t lintRange2 = lintRange1 + lintCount;

> Possible bug: Why subtract 1?

Because ranges are zero-based for their first argument and 
one-based for their second; ie: something[n..m] where m should 
always be  one-beyond than the one we want.

>> if (lintRange1 >= cast(size_t) 0 && lintRange2 <= 
>> pintSequenceCount) {

> Style: The first half of that condition is pointless. 
> `lintRange1` is unsigned, so it will always be greater than or 
> equal to 0. If you want to defend against overflow, you have to 
> do it before subtracting.

Indeed. Refactored the code (previously were int parameters) and 
got stuck in the wrong place !

All in all, thank you very much for your detailed reply, this 
kind of stuff is what helps me most understanding the language 
nuances :)