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.
