[Issue 18936] Internal error: dmd/backend/cgxmm.c 684
https://issues.dlang.org/show_bug.cgi?id=18936 --- Comment #1 from Walter Bright --- https://github.com/dlang/dmd/pull/8326 is now a fix. --
[Issue 18936] Internal error: dmd/backend/cgxmm.c 684
https://issues.dlang.org/show_bug.cgi?id=18936 Walter Bright changed: What|Removed |Added Keywords||ice-on-valid-code --
[Issue 18944] New: Mixing in new overloads of a function in an object won't resolve the overloads correctly
https://issues.dlang.org/show_bug.cgi?id=18944 Issue ID: 18944 Summary: Mixing in new overloads of a function in an object won't resolve the overloads correctly Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: critical Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: goober...@gmail.com Seems related to ancient issue 9235, but not quote the same. Any additional overloads of a function that are called from the object itself won't resolve. Code example at https://run.dlang.io/is/a85Lbq Changing the code so that every instance of the foo overload is mixed in results in the program compiling and running as expected. I came across this when trying to use mixins as a dodgy way to replicate C#'s partial classes. So this is quite bad as far as usability concerns go. Error strings at time of submission: onlineapp.d(26): Error: function onlineapp.LookAtMe.foo(ref float val) is not callable using argument types (int) onlineapp.d(26):cannot pass argument val of type int to parameter ref float val onlineapp.d(31): Error: function onlineapp.LookAtMe.foo(ref float val) is not callable using argument types (string) onlineapp.d(31):cannot pass argument val of type string to parameter ref float val --
[Issue 18944] Mixing in new overloads of a function in an object won't resolve the overloads correctly
https://issues.dlang.org/show_bug.cgi?id=18944
Simen Kjaeraas changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||simen.kja...@gmail.com
Resolution|--- |INVALID
--- Comment #1 from Simen Kjaeraas ---
Here's a reduced example showing the same issue:
mixin template FooOne() {
void foo(ref int val) {}
}
mixin FooOne!();
void foo(ref float val) {}
unittest {
int n;
// Error: function foo.foo(ref float val) is not callable using argument types
(int)
foo(n);
}
This issue is covered in the documentation of the template mixin feature
(https://dlang.org/spec/template-mixin.html#mixin_scope):
"1. If the name of a declaration in a mixin is the same as a declaration in the
surrounding scope, the surrounding declaration overrides the mixin one"
It also explains how to fix the problem:
"5. Alias declarations can be used to overload together functions declared in
different mixins"
In your example that fix would be:
mixin FooOne!() f1;
mixin FooTwo!() f2;
alias foo = f1.foo;
alias foo = f2.foo;
--
[Issue 18936] Internal error: dmd/backend/cgxmm.c 684
https://issues.dlang.org/show_bug.cgi?id=18936 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18936] Internal error: dmd/backend/cgxmm.c 684
https://issues.dlang.org/show_bug.cgi?id=18936 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/d2884aa5a06f59ec6f4c4ae48ef864037c4d238f fix Issue 18936 - Internal error: dmd/backend/cgxmm.c 684 https://github.com/dlang/dmd/commit/6a210604e16ad1fc64406abec99c5d1b74072b9b Merge pull request #8326 from WalterBright/cgxmm684 fix Issue 18936 - Internal error: dmd/backend/cgxmm.c 684 merged-on-behalf-of: Walter Bright --
[Issue 6447] iota(BigInt) too
https://issues.dlang.org/show_bug.cgi?id=6447
Russel Winder changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME |---
--- Comment #17 from Russel Winder ---
Using LDC on Debian Sid, the code:
import std.bigint: BigInt;
import std.range: iota;
void main() {
auto x = iota(BigInt(10));
}
compiles and executes fine, but the code:
void main() {
import std.bigint: BigInt;
import std.range: iota;
iota(BigInt(1), BigInt(100), BigInt(5));
iota(BigInt(1), BigInt(100), 5);
}
results in:
test_b.d(4): Error: template std.range.iota cannot deduce function from
argument types !()(BigInt, BigInt, BigInt), candidates are:
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5371):
std.range.iota(B, E, S)(B begin, E end, S step) if ((isIntegral!(CommonType!(B,
E)) || isPointer!(CommonType!(B, E))) && isIntegral!S)
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5481):
std.range.iota(B, E)(B begin, E end) if (isFloatingPoint!(CommonType!(B, E)))
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5488):
std.range.iota(B, E)(B begin, E end) if (isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E)))
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5558):
std.range.iota(E)(E end) if (is(typeof(iota(E(0), end
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5567):
std.range.iota(B, E, S)(B begin, E end, S step) if
(isFloatingPoint!(CommonType!(B, E, S)))
test_b.d(4):... (1 more, -v to show) ...
test_b.d(5): Error: template std.range.iota cannot deduce function from
argument types !()(BigInt, BigInt, int), candidates are:
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5371):
std.range.iota(B, E, S)(B begin, E end, S step) if ((isIntegral!(CommonType!(B,
E)) || isPointer!(CommonType!(B, E))) && isIntegral!S)
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5481):
std.range.iota(B, E)(B begin, E end) if (isFloatingPoint!(CommonType!(B, E)))
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5488):
std.range.iota(B, E)(B begin, E end) if (isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E)))
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5558):
std.range.iota(E)(E end) if (is(typeof(iota(E(0), end
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5567):
std.range.iota(B, E, S)(B begin, E end, S step) if
(isFloatingPoint!(CommonType!(B, E, S)))
test_b.d(5):... (1 more, -v to show) ...
Using dmd from d-apt the first code works fine and the second code results in:
test_b.d(4): Error: template `std.range.iota` cannot deduce function from
argument types `!()(BigInt, BigInt, BigInt)`, candidates are:
/usr/include/dmd/phobos/std/range/package.d(5890):`std.range.iota(B, E,
S)(B begin, E end, S step) if ((isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E))) && isIntegral!S)`
/usr/include/dmd/phobos/std/range/package.d(6000):`std.range.iota(B,
E)(B begin, E end) if (isFloatingPoint!(CommonType!(B, E)))`
/usr/include/dmd/phobos/std/range/package.d(6007):`std.range.iota(B,
E)(B begin, E end) if (isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E)))`
/usr/include/dmd/phobos/std/range/package.d(6077):`std.range.iota(E)(E
end) if (is(typeof(iota(E(0), end`
/usr/include/dmd/phobos/std/range/package.d(6086):`std.range.iota(B, E,
S)(B begin, E end, S step) if (isFloatingPoint!(CommonType!(B, E, S)))`
test_b.d(4):... (1 more, -v to show) ...
test_b.d(5): Error: template `std.range.iota` cannot deduce function from
argument types `!()(BigInt, BigInt, int)`, candidates are:
/usr/include/dmd/phobos/std/range/package.d(5890):`std.range.iota(B, E,
S)(B begin, E end, S step) if ((isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E))) && isIntegral!S)`
/usr/include/dmd/phobos/std/range/package.d(6000):`std.range.iota(B,
E)(B begin, E end) if (isFloatingPoint!(CommonType!(B, E)))`
/usr/include/dmd/phobos/std/range/package.d(6007):`std.range.iota(B,
E)(B begin, E end) if (isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E)))`
/usr/include/dmd/phobos/std/range/package.d(6077):`std.range.iota(E)(E
end) if (is(typeof(iota(E(0), end`
/usr/include/dmd/phobos/std/range/package.d(6086):`std.range.iota(B, E,
S)(B begin, E end, S step) if (isFloatingPoint!(CommonType!(B, E, S)))`
test_b.d(5):... (1 more, -v to show) ...
So I think this problem is not fixed.
--
[Issue 18945] New: immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
Issue ID: 18945
Summary: immutable variable is used as if it's an enum
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: CTFE
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
unittest {
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n);
}
The above assert fails - the value of n is calculated using CTFE for the length
of a, and is thus set to 1. Then, at runtime, the value of n is set to 2, and
the assert fails.
It seems to me the issue is that the variable n is being used as a compile-time
constant. The expected behavior is an error message along the lines of
'variable n cannot be read at compile time'.
--
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
Jonathan M Davis changed:
What|Removed |Added
CC||issues.dl...@jmdavisprog.co
||m
--- Comment #1 from Jonathan M Davis ---
Yeah. And bizarrely, this code actually results in an error about not being
able to call stuff during CTFE:
int foo()
{
import std.datetime;
return cast(int)Clock.currTime().stdTime;
}
void main()
{
immutable i = foo();
int[i] arr;
}
Getting rid of the declaration for arr fixes the problem. So, clearly, the
compiler is currently deciding whether it should do CTFE on an immutable, local
variable based on whether it's then used in a context where its value must be
known at compile time instead of forcing enum to be used instead. It also seems
to do the same with const.
The fact that the static array's size can use a local variable is completely
inconsistent with how CTFE normally works and makes the whole situation that
much more confusing. CTFE should only be kicking in based on whether the value
is actually needed at compile time and not based on whether the variable that
it's assigned to is then used at compile time.
--
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
--- Comment #2 from David Bennett ---
Disclaimer: Just a D user, I hold no decision making power or insight into the
history here.
const and immutable are runtime lvalues that have a known way to get "a" value
at compiletime. As you have noticed the runtime and compiletime values could be
different. Here is another example to show the same effect.
---
unittest {
immutable n = __ctfe ? 1 : 2;
enum j = n;
assert(n == j);
}
---
If you wanted to opt-in to making sure you could only use n at runtime you
could make it a `static immutable` but this has the effect of running the
assignment expression at compiletime.
I believe the current functionality is being used in various projects so I dont
see this being changed without at least a deprecation process. For example,
I've seen sending const variables as template parameters more than a few times.
As for my personal opinion on this issue, I believe using const and immutable
at compiletime is useful, it's just that the values could be different that's
confusing.
So I believe the current reasoning goes like this:
immutable values are theoretically known at compile time so why not use
them.
It's not always possible to ctfe so runtime immutable is assigned at
runtime.
But the runtime value is not known at compiletime, so when it's used we do
the ctfe then and error if it cant.
--
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
--- Comment #3 from Jonathan M Davis ---
This probably does need to be removed via deprecation rather than simply making
it an error, but allowing it is exactly the sort of thing that increases the
confusion about how CTFE works and when it's used. Currently,
immutable i = foo();
doesn't do CTFE. But
immutable i = foo();
int[i] arr;
does, and that muddies the waters considerably. We already have problems due to
folks getting really confused about why stuff like
auto foo(int i)
{
return bar!i();
}
isn't legal, and allowing a runtime variable to be used just because it's
immutable makes that worse - even more so when you consider that
auto foo(immutable int i)
{
return bar!i();
}
won't work, and neither will
auto foo(immutable int i = 42)
{
return bar!i();
}
And allowing
immutable i = foo();
int[i] arr;
to work doesn't even buy us anything. You could simply use enum instead of
immutable, and it works perfectly fine.
My guess is that the current behavior was added because of an enhancement
request, and the person who implemented it didn't think of all of the
consequences that result from that decision (including the issue with __ctfe).
But I definitely think that we'd be better off if you _had_ to use an enum in
this case and that the fact that a variable was const or immutable would have
zero effect on CTFE.
--
[Issue 18946] New: assert message can throw hijacking the assert failure.
https://issues.dlang.org/show_bug.cgi?id=18946
Issue ID: 18946
Summary: assert message can throw hijacking the assert failure.
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: iamthewilsona...@hotmail.com
from https://forum.dlang.org/thread/pf5gm7$14gb$1...@digitalmars.com
import std.stdio;
import core.exception;
// mess with the compiler's reasoning about the truthiness
// of the assert, otherwise the trailing catches are removed
// as dead code, triggering the implicit one around Dmain
bool returnsFalse() { return false;}
void main() {
try {
static string throwingFunc() {
throw new Exception("An exception");
}
assert(returnsFalse(), throwingFunc());
} catch(Exception ex) {
writeln("Exception");
} catch(AssertError ex) {
writeln("Assert");
}
}
prints
Exception
the compiler should be at least warn that the message expression is not
nothrow. but we should probably deprecate it.
--
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
David Bennett changed:
What|Removed |Added
CC||davidbenn...@bravevision.co
||m
--- Comment #4 from David Bennett ---
I'm not sure what workaround we would recommend in the deprecation messaged as
the current functionality is actually hard to replicate... as enum and static
would give a different runtime result (actually an error in this case as __ctfe
is not known at statictime... only ctfetime and runtime)
The best I could do on short notice was:
unittest {
immutable n = __ctfe ? 1 : 2;
enum l = {return __ctfe ? 1 : 2;}();
int[l] a;
assert(a.length == n);
}
--
[Issue 18946] assert message can throw hijacking the assert failure.
https://issues.dlang.org/show_bug.cgi?id=18946 Shachar Shemesh changed: What|Removed |Added CC||shac...@weka.io --
[Issue 18947] New: No way to get list of overloads from template mixins
https://issues.dlang.org/show_bug.cgi?id=18947
Issue ID: 18947
Summary: No way to get list of overloads from template mixins
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
mixin template foo(T) {
void fun(T) {}
}
struct S {
mixin foo!int;
mixin foo!string;
}
unittest {
static assert(__traits(compiles, __traits(getMember, S, "fun")));
static assert(__traits(getOverloads, S, "fun").length == 0);
S s;
s.fun(3);
}
Somehow the call to s.fun compiles, but trying to get the list of overloads
fails.
--
[Issue 18948] New: std.uni.toLower and std.uni.toUpper should work with random access ranges
https://issues.dlang.org/show_bug.cgi?id=18948 Issue ID: 18948 Summary: std.uni.toLower and std.uni.toUpper should work with random access ranges Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com --
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
anonymous4 changed:
What|Removed |Added
Hardware|x86 |All
OS|Windows |All
--- Comment #5 from anonymous4 ---
---
int f(in int a) pure
{
return a;
}
void g()
{
immutable int a=0;
static assert(f(a)==0);
}
---
This works.
---
int f(in ref int a) pure
{
return a;
}
void g()
{
immutable int a=0;
static assert(f(a)==0);
}
---
This doesn't.
--
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #6 from Jonathan M Davis --- (In reply to David Bennett from comment #4) > I'm not sure what workaround we would recommend in the deprecation messaged > as the current functionality is actually hard to replicate. Just use an enum if you want the value to be known and used at compile time, and use an immutable variable if you want it to be known and used at runtime. Don't try to have a variable with different values at compile time and runtime. And if for some reason, you want the value calculated at compile time but to still have a variable, then use an enum to initialize the immutable variable. That's what you have to do with mutable variables already. --
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #7 from David Bennett --- (In reply to Jonathan M Davis from comment #6) > > Just use an enum if you want the value to be known and used at compile time, > and use an immutable variable if you want it to be known and used at > runtime. Don't try to have a variable with different values at compile time > and runtime. And if for some reason, you want the value calculated at > compile time but to still have a variable, then use an enum to initialize > the immutable variable. That's what you have to do with mutable variables > already. So the deprecation message shouldn't have a concrete example to opt-in to keep the current functionality. Just something like "Deprecation: Using an immutable variable at compile time will be removed in a future version. Try changing `n` in `int[n] a;` to use an enum variable.". And assume D users will know that they will need to implement the enum separately from the immutable if they want to keep the status quo? Then there are immutable struct members used at compile time, they might not be easy to convert to an enum. https://run.dlang.io/is/cfGfxw I've never seen it used like that... but it does work currently. --
[Issue 18948] std.uni.toLower and std.uni.toUpper should work with random access ranges
https://issues.dlang.org/show_bug.cgi?id=18948 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/fa5830c32ee08c34bdfc10bfb62dd7cb5ee87ba3 Fix Issue 18948 - toLower and toUpper should work with random access ranges https://github.com/dlang/phobos/commit/cc58e8a7bf3dec7004cdd9511df927ba38cdeb3c Merge pull request #6545 from JackStouffer/toCase-random-access Issue 18948 - std.uni.toLower and std.uni.toUpper should work with random access ranges merged-on-behalf-of: Jack Stouffer --
[Issue 18948] std.uni.toLower and std.uni.toUpper should work with random access ranges
https://issues.dlang.org/show_bug.cgi?id=18948 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #8 from David Bennett --- (In reply to David Bennett from comment #7) > Then there are immutable struct members used at compile time, they might not > be easy to convert to an enum. > https://run.dlang.io/is/cfGfxw > I've never seen it used like that... but it does work currently. Actually, I reduced that last case a bit to much that it would work fine even with this change... --
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #9 from David Bennett --- (In reply to David Bennett from comment #8) > (In reply to David Bennett from comment #7) > > Then there are immutable struct members used at compile time, they might not > > be easy to convert to an enum. > > https://run.dlang.io/is/cfGfxw > > I've never seen it used like that... but it does work currently. > > Actually, I reduced that last case a bit to much that it would work fine > even with this change... Here is the case I was thinking of: https://run.dlang.io/is/zZWdIQ Only works currently with static immutable, so not sure if it could be a problem as I think this change would only effect immutable (without static). sorry for the noise. --
[Issue 18470] std.algorithm.splitter has frame access problems for custom preds
https://issues.dlang.org/show_bug.cgi?id=18470 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18470] std.algorithm.splitter has frame access problems for custom preds
https://issues.dlang.org/show_bug.cgi?id=18470 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/b5162ecc014a33b5866f2de62b5af012cf425c1d fix issue 18470 - std.algorithm.splitter has frame access problems for custom preds https://github.com/dlang/phobos/commit/a6bf2b6c4793f6af9f6aa148f6bf603b702fb942 Merge pull request #6522 from BBasile/issue-18470 fix issue 18470 - std.algorithm.splitter has frame access problems for custom preds merged-on-behalf-of: Jack Stouffer --
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 ag0aep6g changed: What|Removed |Added CC||ag0ae...@gmail.com --
[Issue 18949] New: Array literals don't work with betterc
https://issues.dlang.org/show_bug.cgi?id=18949
Issue ID: 18949
Summary: Array literals don't work with betterc
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johnnymar...@gmail.com
--- bug.d
void takeArray(const(int)[] array)
{
}
void bar()
{
takeArray([1, 2, 3]);
}
> dmd -c -betterc bug.d
bug.d(6): Error: `TypeInfo` cannot be used with -betterC
It looks like passing an array literal to a function parameter creates a
dependency on `TypeInfo`. It think this has to do with how D is handling the
array literal. It might be trying to allocate it using the GC which is causing
it to depend on GC. You can make the example work if you change bar to the
following:
void bar()
{
static arr = [1, 2, 3];
takeArray(arr);
}
However, I think both versions should work. Otherwise, a better error message
should be in order, i.e.
bug.d(6): dynamic array literals are not supported in betterC. you can fix
this by assigning the array to a static variable instead.
--
[Issue 18846] VisualD - show vtable in debugger
https://issues.dlang.org/show_bug.cgi?id=18846 Manu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Manu --- Seems to be working well! --
[Issue 18639] VisualD - First 5 minutes - Improve list of project wizards, propritise MSBuild projects
https://issues.dlang.org/show_bug.cgi?id=18639 Manu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Manu --- Situation is much better! --
[Issue 16692] New debug experience: possible to execute pure functions during expression evaluation?
https://issues.dlang.org/show_bug.cgi?id=16692 --- Comment #10 from Manu --- Okay, that's awesome! Seems to work well. So for const pure properties (or methods that look like properties) where it's safe to call them without mutating, is it possible to automatically populate the struct/class with phony members for the property getters? Ideally they would have a different little icon than data members (like C# does with its properties). --
[Issue 16692] New debug experience: possible to execute pure functions during expression evaluation?
https://issues.dlang.org/show_bug.cgi?id=16692 --- Comment #11 from Rainer Schuetze --- I'm currently still trying to figure out how to deal with slices and delegates, because they are returned in a way incompatible with any C++ ABI. There is currently no annotation of pure or const in the debug info, and I have so far avoided adding a demangler. Not sure about automatically showing them for any class or struct, maybe I should have a look how it works in C#. I'm currently leaning towards making them available for explicit use in some kind of visualizer, so you can also avoid repeating the same information by property functions and private members when showing the struct. --
