mixin template's alias parameter ... ignored ?

[someone]

On Monday, 12 July 2021 at 23:28:29 UTC, ag0aep6g wrote:

> `scope` is not a visibility level.

Well, that explains why it is not listed among the visibility 
attributes to begin with -something that at first glance seemed 
weird to me.

> `lstrSequence` is local to the function, so visibility 
> (`public`, `private`, ...) doesn't even apply.

Being *local* to ... ain't imply visibility too regardless scope 
not being a visibility attribute ? I mean, scope is restricting 
the variable to be leaked outside the function/whatever and to me 
it seems like restricted to be seen from the outside. *Please 
note* that I am not making an argument against the 
implementation, I am just trying to understand why it is not 
being classified as another visibility attribute given that 
more-or-less has the same concept as a local variable like in 
other languages.

> Most likely, you don't have any use for `scope` at the moment.

Almost sure if you say so given your vast knowledge of D against 
my humble first steps LoL.

> You're obviously not compiling with `-preview=dip1000`.

Nope. I didn't knew it even existed.

> And neither should you, because the feature is not ready for a 
> general audience yet.

ACK.

> [...]
>>> 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.
>
> I'm not sure where we stand with `in`

You mean *we* = D developers ?

> but let's say that it means `scope const`

This I stated because I read it somewhere in the docs, it was not 
my assumption.

> The `scope` part of `scope const` still does nothing to a 
> `size_t`.
> These are all the same:

> in size_t
> const size_t
> scope const size_t

OK. Specifically to integers nothing then. But, what about 
strings and whatever else ? I put them more-or-less as a general 
rule or so was the idea when I replaced the in's in the 
parameters app-wide.

>>>> 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.
>
> That doesn't make sense. A length of zero is perfectly fine. 
> It's just an empty range. You're making `lintStart` one-based 
> for no reason.

For a UDT like mine I think it has a lot of sense because when I 
think of a string and I want to chop/count/whatever on it my mind 
works one-based not zero-based. Say "abc" needs b my mind works a 
lot easier mid("abc", 2, 1) than mid("abc", 1, 1) and besides I 
am *not* returning a range or a reference slice to a range or 
whatever I am returning a whole new string construction. If I 
would be returning a range I will follow common sense since I 
don't know what will be done thereafter of course.