On Tuesday, 13 July 2021 at 05:37:49 UTC, ag0aep6g wrote:
On 13.07.21 03:03, someone wrote:
On Monday, 12 July 2021 at 23:28:29 UTC, ag0aep6g wrote:
[...]
I'm not sure where we stand with `in`
You mean *we* = D developers ?
Yes. Let me rephrase and elaborate: I'm not sure what the
On Tuesday, 13 July 2021 at 05:26:56 UTC, Ali Çehreli wrote:
Cumbersome because one has to make sure existing casts are
correct after changing a type.
ACK.
Harmful because it bypasses the compiler's type checking.
Hmmm ... I'll be reconsidering my cast usage approach then.
>> For
On 13.07.21 03:03, someone wrote:
On Monday, 12 July 2021 at 23:28:29 UTC, ag0aep6g wrote:
[...]
I'm not sure where we stand with `in`
You mean *we* = D developers ?
Yes. Let me rephrase and elaborate: I'm not sure what the current status
of `in` is. It used to mean `const scope`. But
On 7/12/21 5:42 PM, someone wrote:
> On Monday, 12 July 2021 at 23:25:13 UTC, Ali Çehreli wrote:
>> On 7/12/21 3:35 PM, someone wrote:
>>
>> >>> private size_t pintSequenceCurrent = cast(size_t) 0;
>> >
>> >> Style: There's no need for the casts (throughout).
>> >
>> > [...] besides, it won't
On Tuesday, 13 July 2021 at 02:34:07 UTC, Mike Parker wrote:
On Tuesday, 13 July 2021 at 02:22:46 UTC, Mike Parker wrote:
On Tuesday, 13 July 2021 at 01:03:11 UTC, someone wrote:
Being *local* to ... ain't imply visibility too regardless
scope not being a visibility attribute ? I mean, scope
On Tuesday, 13 July 2021 at 02:22:46 UTC, Mike Parker wrote:
Hopefully, my post above will shed some light on this.
Yes Mike, a *lot*.
Your previous example was crystal-clear -it makes a lot of sense
for some class usage scenarios I am thinking of but not for what
I did with my example.
On Tuesday, 13 July 2021 at 02:22:46 UTC, Mike Parker wrote:
On Tuesday, 13 July 2021 at 01:03:11 UTC, someone wrote:
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
On Tuesday, 13 July 2021 at 01:03:11 UTC, someone wrote:
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
On Monday, 12 July 2021 at 23:45:57 UTC, someone wrote:
Regarding -preview=dip1000 (and the explicit error description
that could have helped me a lot back then) : DMD man page says
the preview switch lists upcoming language features, so DIP1000
is something like a D proposal as I glanced
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
On Monday, 12 July 2021 at 23:25:13 UTC, Ali Çehreli wrote:
On 7/12/21 3:35 PM, someone wrote:
>>> private size_t pintSequenceCurrent = cast(size_t) 0;
>
>> Style: There's no need for the casts (throughout).
>
> [...] besides, it won't hurt, and it helps me in many ways.
I think you are doing
On Monday, 12 July 2021 at 23:18:57 UTC, jfondren wrote:
On Monday, 12 July 2021 at 22:35:27 UTC, someone wrote:
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 ...
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
On 7/12/21 3:35 PM, someone wrote:
>>> private size_t pintSequenceCurrent = cast(size_t) 0;
>
>> Style: There's no need for the casts (throughout).
>
> [...] besides, it won't hurt, and it helps me in many ways.
I think you are doing it only for literal values but in general, casts
can be very
On Monday, 12 July 2021 at 22:35:27 UTC, someone wrote:
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
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
On 12.07.21 03:37, someone wrote:
I ended up with the following (as usual advice/suggestions welcomed):
[...]> alias stringUTF16 = dstring; /// same as immutable(dchar)[];>
alias stringUTF32 = wstring; /// same as immutable(wchar)[];
Bug: You mixed up `wstring` and `dstring`. `wstring` is
On Sunday, 11 July 2021 at 05:54:48 UTC, Ali Çehreli wrote:
Ali
Primarily to Ali & Steve for their help, be advised, this post
will be somehow ... long.
Some bit of background to begin with: a week or so ago I posted
asking advice on code safeness, and still I didn't reply to the
ones
On Sunday, 11 July 2021 at 12:49:28 UTC, Adam D Ruppe wrote:
Indeed, you'd have to mixin the whole thing like
mixin("public struct " ~ lstrStructureId ~ " { ... } ");
As I mentioned in my previous reply to Ali this could be viable
for one-liners-or-so, but for chunks of code having, say, a
On Sunday, 11 July 2021 at 13:14:23 UTC, Steven Schveighoffer
wrote:
when I've done this kind of stuff, what I usually do is:
```d
struct Thing {
... // actual struct
}
mixin("alias ", lstrStructureID, " = Thing;");
```
the downside is that the actual struct name symbol will be
`Thing`,
On Sunday, 11 July 2021 at 14:04:14 UTC, zjh wrote:
just genenrate `lstrStructureID` struct.
```d
mixin template templateUGC ( typeStringUTF, alias
lstrStructureID){
public struct lstrStructureID {
typeStringUTF w;
}
}
mixin templateUGC!(string, "gudtUGC08");
```
You say `This creates a struct with teh literal name
lstrStructureID`.
I tried,can compile,but I don't know
On Sunday, 11 July 2021 at 13:30:27 UTC, zjh wrote:
Could you explain more detail?
It is just normal code with a normal name. The fact there's
another variable with the same name doesn't change anything.
On Sunday, 11 July 2021 at 12:49:28 UTC, Adam D Ruppe wrote:
This creates a struct with teh literal name `lstrStructureID`.
Just like any other name. So it is NOT the value of the
variable.
Could you explain more detail?
On 7/11/21 8:49 AM, Adam D Ruppe wrote:
On Sunday, 11 July 2021 at 05:20:49 UTC, someone wrote:
```d
mixin template templateUGC (
typeStringUTF,
alias lstrStructureID
) {
public struct lstrStructureID {
typeStringUTF whatever;
}
This creates a struct with teh literal
On Sunday, 11 July 2021 at 05:20:49 UTC, someone wrote:
```d
mixin template templateUGC (
typeStringUTF,
alias lstrStructureID
) {
public struct lstrStructureID {
typeStringUTF whatever;
}
This creates a struct with teh literal name `lstrStructureID`.
Just like any
On Sunday, 11 July 2021 at 05:54:48 UTC, Ali Çehreli wrote:
The only way that I know is to take a string parameter and use
it with a string mixin:
Yes, that I tried, but the structure has a lot of lines of codes
and so it is impractical and of course it will turn out difficult
to debug.
On 7/10/21 10:20 PM, someone wrote:
> mixin template templateUGC (
> typeStringUTF,
> alias lstrStructureID
> ) {
>
> public struct lstrStructureID {
The only way that I know is to take a string parameter and use it with a
string mixin:
mixin template templateUGC (
```d
mixin template templateUGC (
typeStringUTF,
alias lstrStructureID
) {
public struct lstrStructureID {
typeStringUTF whatever;
}
}
mixin templateUGC!(string, "gudtUGC08");
mixin templateUGC!(dstring, "gudtUGC16");
mixin templateUGC!(wstring, "gudtUGC32");
void
29 matches
Mail list logo
