Re: What are some ways to get more strict type-checking?
On Monday, 6 May 2019 at 02:02:52 UTC, Devin wrote: Recently, I poorly refactored some code, which introduced an obvious bug. But to my astonishment, the broken code compiled without any warnings or notifications. A minimum example is shown below: alias ID = uint; ... alias doesn't create a distinct type, but maybe Typedef from Phobos is what you want: https://dlang.org/library/std/typecons/typedef.html
What are some ways to get more strict type-checking?
Recently, I poorly refactored some code, which introduced an
obvious bug. But to my astonishment, the broken code compiled
without any warnings or notifications. A minimum example is
shown below:
alias ID = uint;
struct Data
{
ID id;
this(ID id)
{
this.id = id;
}
}
// Forgot to refactor a function to return its
// loaded data, rather than a success/fail bool
bool load_data()
{
// some processing
return true;
}
int main()
{
// Very obviously a bug,
// but it still compiles
Data d = load_data();
return 0;
}
So I'm assigning a boolean value to a struct with one uint field.
The compiler interprets the attempted assignment as calling the
constructor with one argument, and then converts the boolean to a
uint to match the function overload. So in effect, my struct is
implicitly convertible from a bool.
My question is basically... how do I make this not compile? What
methods do I have to prevent this sort of crazy implicit
conversion? I'm not familiar enough with the language to know my
options. I think there are a few:
* Enable more warnings. DMD seems to only have "-w", which I
believe is enabled through dub. Are there more pedantic settings
that would catch this conversion?
* Change "ID" from an alias to a struct of some sort. I've been
trying to find similar issues, and I saw once suggested that a
person could make a struct with one member and conversions to and
from different types. I've also seen "alias X this;" a lot. But
my main issues is stopping these conversions, and everything I've
seen is about enabling automatic conversion. Ideally, I would
have something that's convertible TO a uint when needed, but
can't be converted FROM other data types.
* Replace the constructor with a static function. This happened
because D implicitly converted my assignment into a constructor
call. If I just don't have constructors, and instead define a
static function to build instances of the struct, I could then
have more control over assignment and avoid this more easily.
If anyone has other options, I would really want to hear them. I
know for a fact these types of issues are going to crop up in my
project, and I want to nip them in the bud before the become
harder to track down.
Re: alias to fully qualified symbol gives error, but when module is also a symbol
On Sunday, 5 May 2019 at 18:07:10 UTC, Adam D. Ruppe wrote: The std.stdio one is supposed to be an error; the old buggy behavior was to bypass the private import in these cases and that is why it is deprecated pending changes. Thanks, that answers my question. The old private-bypassing behavior is apparently more broken than I thought.
Re: Compiler/Phobos/Types problem — panic level due to timing.
On Sunday, 5 May 2019 at 19:18:47 UTC, lithium iodate wrote: On Sunday, 5 May 2019 at 18:53:08 UTC, Russel Winder wrote: Hi, I had merrily asumed I could implement nth Fibonacci number with: takeOne(drop(recurrence!((a, n) => a[n-1] + a[n-2])(zero, one), n)).front where zero and one are of type BigInt, and n is of type size_t. However both dmd and ldc2 complain saying: […] I am now at the WTF stage – how can I show this example on Thursday in my DevoxxUK presentation? I am close to giving up and imbibing of too much Pernod. `recurrence` takes the `CommonType` of the initial values and declares its internal state as an array of this type, however when at least one of the values is const or immutable, the `CommonType` is const too, or even immutable in the case when all values are immutable. The state being const/immutable means that the following step, initializing it, can't work, since, well, the array cannot be modified (hence the errors). I'd say this can be considered to be a bug with `recurrence`. You can solve this issue by constructing and passing mutable versions of `one` and `zero` to `recurrence`. Yep https://run.dlang.io/is/XsLrRz works for me, https://run.dlang.io/is/KxY0e9 doesn't.
Re: Compiler/Phobos/Types problem — panic level due to timing.
On Sunday, 5 May 2019 at 18:53:08 UTC, Russel Winder wrote: Hi, I had merrily asumed I could implement nth Fibonacci number with: takeOne(drop(recurrence!((a, n) => a[n-1] + a[n-2])(zero, one), n)).front where zero and one are of type BigInt, and n is of type size_t. However both dmd and ldc2 complain saying: […] I am now at the WTF stage – how can I show this example on Thursday in my DevoxxUK presentation? I am close to giving up and imbibing of too much Pernod. `recurrence` takes the `CommonType` of the initial values and declares its internal state as an array of this type, however when at least one of the values is const or immutable, the `CommonType` is const too, or even immutable in the case when all values are immutable. The state being const/immutable means that the following step, initializing it, can't work, since, well, the array cannot be modified (hence the errors). I'd say this can be considered to be a bug with `recurrence`. You can solve this issue by constructing and passing mutable versions of `one` and `zero` to `recurrence`.
Re: Any full feature xml library available?
On Fri, 2019-05-03 at 14:07 -0700, H. S. Teoh via Digitalmars-d-learn wrote: > […] > The problem is that while there is no shortage of complaints about XML > support in D, there is a great dearth of people actually willing to *do* > something about it. In my case it is because I have no need to deal with XML using D, and I am not in the market for paid work. Those actually doing stuff with XML and D have far fewer excuses. > At least Jonathan wrote dxml, which arguably would meet the need in most > cases. So there's that. But if somebody wants entity references and > other similar things, the only recourse would appear to be to wrap > libxml2. Given D's aptitude at interfacing with C, this should be much > simpler than writing dxml. It just needs someone to sit down and *do* > it. That people who have the problem can write many lengthy emails on the D lists rather than doing something about creating a D binding to libxml2 is clearly the bulk of the problem. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Compiler/Phobos/Types problem — panic level due to timing.
Hi, I had merrily asumed I could implement nth Fibonacci number with: takeOne(drop(recurrence!((a, n) => a[n-1] + a[n-2])(zero, one), n)).front where zero and one are of type BigInt, and n is of type size_t. However both dmd and ldc2 complain saying: /usr/include/dmd/phobos/std/range/package.d(5770): Error: template std.bigint.BigInt.opAssign cannot deduce function from argument types !()(immutable(BigInt)) immutable, candidates are: /usr/include/dmd/phobos/std/bigint.d(178): std.bigint.BigInt.opAssign(T)(T x) if (isIntegral!T) /usr/include/dmd/phobos/std/bigint.d(194):std.bigint.BigInt.opAssign(T : BigInt)(T x) /usr/include/dmd/phobos/std/range/package.d(5770): Error: template std.bigint.BigInt.opAssign cannot deduce function from argument types !()(immutable(BigInt)) immutable, candidates are: /usr/include/dmd/phobos/std/bigint.d(178): std.bigint.BigInt.opAssign(T)(T x) if (isIntegral!T) /usr/include/dmd/phobos/std/bigint.d(194):std.bigint.BigInt.opAssign(T : BigInt)(T x) fibonacci.d(25): Error: template instance `fibonacci.declarative.recurrence!((a, n) => a[n - 1] + a[n - 2], immutable(BigInt), immutable(BigInt))` error instantiating /usr/include/dmd/phobos/std/range/package.d(5720): Error: template std.bigint.BigInt.opAssign cannot deduce function from argument types !()(immutable(BigInt)) immutable, candidates are: /usr/include/dmd/phobos/std/bigint.d(178): std.bigint.BigInt.opAssign(T)(T x) if (isIntegral!T) /usr/include/dmd/phobos/std/bigint.d(194):std.bigint.BigInt.opAssign(T : BigInt)(T x) /usr/include/dmd/phobos/std/range/package.d(3177): Error: template instance `std.range.primitives.isInputRange!(Recurrence!(__lambda2, immutable(BigInt), 2LU))` error instantiating fibonacci.d(25): Error: template std.range.drop cannot deduce function from argument types !()(Recurrence!(__lambda2, immutable(BigInt), 2LU), immutable(ulong)), candidates are: /usr/include/dmd/phobos/std/range/package.d(3176):std.range.drop(R)(R range, size_t n) if (isInputRange!R) I am now at the WTF stage – how can I show this example on Thursday in my DevoxxUK presentation? I am close to giving up and imbibing of too much Pernod. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: alias to fully qualified symbol gives error, but when module is also a symbol
On Sunday, 5 May 2019 at 15:22:31 UTC, Dennis wrote:
I was trying to rename an imported `sqrt` (wrongly), but I
stumbled upon this weird behavior:
```
void main() {
import core.stdc.math: sqrtf, sqrt;
alias sqrtd = core.stdc.math.sqrt;
auto a = sqrtd(1);
}
```
onlineapp.d(3): Error: undefined identifier core.stdc.math.sqrt
You didn't actually import the name `core` there, only the
specific symbols `sqrtf` and `sqrt`, which are now considered
direct children of your scope. So it doesn't know where to begin
with that fully qualified name - it doesn't know what `core` is.
So this is working as designed by the module and name lookup
rules.
The std.stdio one is supposed to be an error; the old buggy
behavior was to bypass the private import in these cases and that
is why it is deprecated pending changes.
Re: Can't use threads
On Sunday, 5 May 2019 at 12:28:34 UTC, Aldo wrote: On Sunday, 5 May 2019 at 03:32:37 UTC, Andre Pany wrote: On Saturday, 4 May 2019 at 22:29:26 UTC, Aldo wrote: Does it work on windows if you compile it it as 64 bit application (-m64 argument if I remember correctly, dub argument -a x86_64)? On linux and Darwin 64 is default while on windows 32 bit architecture is default. Kind regards Andre No. I tried to compile it as 64 bit and 32, I lowered ubyte[] data to 4096, and I still have this exception. Used dub and dmd -i to compile. Thats weird. What I can see from source code in DRuntime, windows api GetThreadContext is failing, therefore the error message you can see. Can you test it with a recent version of dmd and if error still exists, please file an issue on issues.dlang.org Kind regards Andre
alias to fully qualified symbol gives error, but when module is also a symbol
I was trying to rename an imported `sqrt` (wrongly), but I
stumbled upon this weird behavior:
```
void main() {
import core.stdc.math: sqrtf, sqrt;
alias sqrtd = core.stdc.math.sqrt;
auto a = sqrtd(1);
}
```
onlineapp.d(3): Error: undefined identifier core.stdc.math.sqrt
However, when std.stdio is imported:
```
void main() {
import std.stdio;
import core.stdc.math: sqrtf, sqrt;
alias sqrtd = core.stdc.math.sqrt;
auto a = sqrtd(1);
}
```
onlineapp.d(4): Deprecation: std.stdio.core is not visible from
module onlineapp
onlineapp.d(4): Deprecation: std.stdio.core is not visible from
module onlineapp
Apart from the deprecation, it actually works. What is the
intended behavior here? Is this a new issue, or does the
deprecation already cover it once it becomes an error?
(Btw the correct way to do this is `import core.stdc.math: sqrtf,
sqrtd = sqrt;`)
Re: Run code before dub dependency's `shared static this()`
On Sunday, 5 May 2019 at 08:24:29 UTC, Vladimirs Nordholm wrote:
Hello.
I have dub dependency which has a `shared static this()`.
In my project, can I run code code before the dependency's
`shared static this()`?
This might work:
pragma(crt_constructor)
extern(C)
void early_init()
{
}
Re: Can't use threads
On Sunday, 5 May 2019 at 03:32:37 UTC, Andre Pany wrote: On Saturday, 4 May 2019 at 22:29:26 UTC, Aldo wrote: Does it work on windows if you compile it it as 64 bit application (-m64 argument if I remember correctly, dub argument -a x86_64)? On linux and Darwin 64 is default while on windows 32 bit architecture is default. Kind regards Andre No. I tried to compile it as 64 bit and 32, I lowered ubyte[] data to 4096, and I still have this exception. Used dub and dmd -i to compile. Thats weird.
Re: Run code before dub dependency's `shared static this()`
On Sunday, 5 May 2019 at 08:24:29 UTC, Vladimirs Nordholm wrote: Hello. I have dub dependency which has a `shared static this()`. In my project, can I run code code before the dependency's `shared static this()`? "Static constructors within a module are executed in the lexical order in which they appear. All the static constructors for modules that are directly or indirectly imported are executed before the static constructors for the importer." Source: https://dlang.org/spec/class.html#static-constructor
Re: Can't use threads
DMD32 D Compiler v2.084.0 code comiled by command dmd -i "test.d" On Sunday, 5 May 2019 at 09:31:13 UTC, zabruk wrote: It works for me (Microsoft Windows [Version 10.0.17134.706] 64-bit) start! start! start! end! end! end! start! start! end! start! end! end!
Re: Can't use threads
It works for me (Microsoft Windows [Version 10.0.17134.706] 64-bit) start! start! start! end! end! end! start! start! end! start! end! end!
Run code before dub dependency's `shared static this()`
Hello. I have dub dependency which has a `shared static this()`. In my project, can I run code code before the dependency's `shared static this()`?
