mixin template's alias parameter ... ignored ?

[ag0aep6g]

On Monday, 12 July 2021 at 22:35:27 UTC, someone wrote:
> On Monday, 12 July 2021 at 05:33:22 UTC, ag0aep6g wrote:
[...]
> 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 ?

`scope` is not a visibility level.

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

Most likely, you don't have any use for `scope` at the moment. 
You're obviously not compiling with `-preview=dip1000`. And 
neither should you, because the feature is not ready for a 
general audience yet.

[...]
>> 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`, but let's say that it 
means `scope const`. 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`.

>>> 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.