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.
