Re: Implicit nothrow with -betterC

[Manuel Maier via Digitalmars-d-learn]

Thanks Adam, that cleared it up for me.

Implicit nothrow with -betterC

[Manuel Maier via Digitalmars-d-learn]

I've been experimenting with the -betterC switch and stumbled 
upon something that didn't quite make sense to me.


I've put together a small example [1] of Win32 code with a window 
callback that has to be nothrow as per the definition of WNDPROC 
somewhere in core.sys.windows. However, calling anything from 
within the window callback not marked as nothrow will result in a 
compile error. This behavior is expected for regular D code and 
there are many ways to fix the code so the compiler no longer 
emits the error. What bugs me is the following.


According to the docs, exceptions "won't work":

From https://dlang.org/spec/betterc.html#consequences
As no Druntime is available, many D features won't work. For 
example:

[...]
7. Exceptions
[...]


To me, this means it should be impossible to write -betterC code 
that throws exceptions. So shouldn't -betterC imply nothrow on 
all functions by default? Is this a compiler bug? If not, in what 
way is the explicit nothrow attribute still useful for -betterC?



[1] 
https://gist.github.com/Manuzor/81cc01d57543202d68eab5a84d944027

Casting a class variable to void*

[Manuel Maier via Digitalmars-d-learn]

I'm not sure whether I've found a bug or if I found some very 
strange but intended behavior. If it is indeed intended behavior, 
I'd like to know the rationale behind it because this one 
surprised me a lot when I found it out after 16+ hours of 
debugging...


Have a look at this code snippet:

```
import std.stdio;

struct Data {}

class Foo {
  Data data;
  alias data this;
}

class Bar {}

class Baz {
  int data = 0xDeadBeef;
  alias data this;
}

void main() {
  auto foo = new Foo();
  //auto rawFoo = cast(void*)foo; // Doesn't compile
  auto rawFoo = *cast(void**) // This works...
  auto bar = new Bar();
  auto rawBar = cast(void*)bar; // This works, as expected.
  auto baz = new Baz();
  auto rawBaz = cast(void*)baz; // Compiles, but...

  writefln("foo: 0x%0.8x", rawFoo);
  writefln("bar: 0x%0.8x", rawBar);
  writefln("baz: 0x%0.8x", rawBaz);
}
```

Here's the output:
```
foo: 0x02341010
bar: 0x02341020
baz: 0xdeadbeef
```

So, when I cast a class variable to void* I expect to get the 
pointer to the class' content, no matter what the class' content 
may be. However, when the class is implicitly convertible to 
something else via `alias this` it tries to cast that instead of 
trying the class itself first.


I understand that a class variable is supposed to act as the 
class type itself, not a pointer/reference to it, so when I ask 
that class variable for something that the underlying class 
doesn't have, the `alias this` is consulted. But in the case 
above, the class variable itself is perfectly convertible to a 
void* already, so why would it have to go through `alias this` 
first? Seems like precedence is messed up for classes and `alias 
this`.


So, is this a bug, or is it intended behavior? In case of the 
latter, I'd gladly add it to the documentation.


By the way, I'm using DMD v2.070.2

std.range: Lockstep vs. Zip

[Manuel Maier via Digitalmars-d-learn]

Hi there,

I was wondering why I should ever prefer std.range.lockstep over 
std.range.zip. In my (very limited) tests std.range.zip offered 
the same functionality as std.range.lockstep, i.e. I was able to 
iterate using `foreach(key, value; std.range.zip(...)) {}` which, 
according to the docs, is what std.range.lockstep was supposed to 
be designed for. On top of that, std.range.zip is capable of 
producing a RandomAccessRange, but std.range.lockstep only 
produces something with opApply.


Cheers