Re: opCast in class prevents destroy
On Tuesday, 1 March 2022 at 04:59:49 UTC, Mike Parker wrote: It makes sense to me, and I would say the bug is that it's not documented. Personally it doesn't make sense to me. I don't think it should override default behaviors, but just add onto it, so you can add an additional cast. Right now if you want to add an additional cast then you have to implement ALL the default behaviors and then add your custom cast. That doesn't seem correct to me at least. That's not how the behavior is in most other languages either.
Re: opCast in class prevents destroy
On Tuesday, 1 March 2022 at 04:59:49 UTC, Mike Parker wrote: You could also specialize on `void*`, as that's the type that was failing to compile I meant "instead", not also.
Re: opCast in class prevents destroy
On Tuesday, 1 March 2022 at 04:29:56 UTC, cc wrote:
```d
struct A {}
class B {
A opCast(T : A)() {
return A();
}
}
void main() {
auto b = new B();
destroy(b);
}
```
fails with
```
dmd2\windows\bin\..\..\src\druntime\import\object.d(4209):
Error: template instance `opCast!(void*)` does not match
template declaration `opCast(T : A)()`
main.d(9): Error: template instance `object.destroy!(true, B)`
error instantiating
```
Looks like a similar bug has been reported:
https://issues.dlang.org/show_bug.cgi?id=22635
Is it a bug? It's not documented in the `opCast` documentation,
but it looks like when you define an `opCast` it completely
replaces the default behavior, i.e., whatever type you define as
the target type becomes the only type to which you can attempt to
cast.
It makes sense to me, and I would say the bug is that it's not
documented.
As a workaround, adding an additional opCast:
```d
class B {
A opCast(T : A)() {
return A();
}
auto opCast(T)() {
return cast(T)super;
}
}
```
SEEMS to work. Is that safe? Or are consequences not what I'm
intending?
So what you've done here is specialized on anything convertible
to `A` and then reenabled casts to all other types, i.e., the
default behavior, but with a special exception for `T:A`.
You could also specialize on `void*`, as that's the type that was
failing to compile. Then you're restricted to `void*` and
anything convertible to `A`.
opCast in class prevents destroy
```d
struct A {}
class B {
A opCast(T : A)() {
return A();
}
}
void main() {
auto b = new B();
destroy(b);
}
```
fails with
```
dmd2\windows\bin\..\..\src\druntime\import\object.d(4209): Error:
template instance `opCast!(void*)` does not match template
declaration `opCast(T : A)()`
main.d(9): Error: template instance `object.destroy!(true, B)`
error instantiating
```
Looks like a similar bug has been reported:
https://issues.dlang.org/show_bug.cgi?id=22635
As a workaround, adding an additional opCast:
```d
class B {
A opCast(T : A)() {
return A();
}
auto opCast(T)() {
return cast(T)super;
}
}
```
SEEMS to work. Is that safe? Or are consequences not what I'm
intending?
Re: Colors in Raylib
On Tuesday, 1 March 2022 at 02:42:52 UTC, Steven Schveighoffer wrote: On 2/28/22 6:48 AM, Salih Dincer wrote: In general, the raylib enumerations are overly verbose for D, e.g. `KeyboardKey.KEY_X`, instead of just `KeyboardKey.X`. I'd love to provide "better enums". In Derelict, I exclusively used anonymous enums with an alias to the base type like Guillaume noted above. When I did bindbc-sdl, I decided to go with named enums + the template I pasted above---I put the mixin at the bottom of each enum declaration. Though I do use anonymous enums now for any that are intended to be used as bit flags. The mixin approach allows you to keep the stronger typing of named enums and still maintain one-to-one compatibility with the with the C source if both are important to you. I'm ambivalent about it now.
Re: Colors in Raylib
On 2/28/22 6:48 AM, Salih Dincer wrote: Hi All, Is there a namespace I should implement in Raylib? For example, I cannot compile without writing Colors at the beginning of the colors: ```Colors.GRAY``` SDB@79 If you refer to raylib-d, that's how it was since I've ever used it. The original C code uses #defines for all the colors. It's an interesting incompatibility issue: 1. C doesn't support enums of anything but ints 2. D doesn't support #define constants I think this is the only reason the colors are not an enum in the C code in the first place. One way to fix this would be to just use individual enums to the raylib-d binding. I think it might have been this way originally. I'm hesitant to change it, but I might define both at some point. In general, the raylib enumerations are overly verbose for D, e.g. `KeyboardKey.KEY_X`, instead of just `KeyboardKey.X`. I'd love to provide "better enums". -Steve
Re: https://run.dlang.io/ vs All dmd compilers (2.060 - latest)
On Monday, 28 February 2022 at 19:00:58 UTC, Matheus wrote: On Monday, 28 February 2022 at 17:49:36 UTC, Mike Parker wrote: ... Please try again. Testing. Matheus. It worked thanks! Matheus.
Re: https://run.dlang.io/ vs All dmd compilers (2.060 - latest)
On Monday, 28 February 2022 at 17:49:36 UTC, Mike Parker wrote: ... Please try again. Testing. Matheus.
Re: Set output location for dub --single
On Monday, 28 February 2022 at 08:03:24 UTC, Basile B. wrote: That 's not exactly what you ask for but you can define the path in the embedded recipe (targetPath) ```d #!/usr/bin/env dub /+ dub.sdl: dependency "mypackage" version="*" path=".." targetPath "./bin" +/ ``` Hey thanks! Not perfect, but it'll probably work. I'll bring up the idea of overriding some settings (such as targetPath) on the command line in a similar manner to ssh in the dub [discussions](https://github.com/dlang/dub/discussions) area and see how well that goes over.
Re: https://run.dlang.io/ vs All dmd compilers (2.060 - latest)
On Monday, 28 February 2022 at 17:44:57 UTC, Matheus wrote: On Monday, 28 February 2022 at 02:31:57 UTC, Mike Parker wrote: ... Hey Parker, I think my IP still under surveillance, everytime I post I get: "Your message has been saved, and will be posted after being approved by a moderator." With VPN I can post without problem. Could you please take a look? Please try again.
Re: https://run.dlang.io/ vs All dmd compilers (2.060 - latest)
On Monday, 28 February 2022 at 02:31:57 UTC, Mike Parker wrote: ... Hey Parker, I think my IP still under surveillance, everytime I post I get: "Your message has been saved, and will be posted after being approved by a moderator." With VPN I can post without problem. Could you please take a look? Matheus.
Re: https://run.dlang.io/ vs All dmd compilers (2.060 - latest)
On Monday, 28 February 2022 at 08:11:15 UTC, Basile B. wrote: This was [reported before]. Apparently this would be caused by a timeout. [reported before]: https://forum.dlang.org/post/skc2dd$1o52$1...@digitalmars.com Apparently yes, but I think the return error should be clear to avoid guessing. I've been trying this for 2 weeks, I think there is something wrong there. Matheus.
Re: Colors in Raylib
On Monday, 28 February 2022 at 12:18:37 UTC, Mike Parker wrote:
```d
enum expandEnum(EnumType, string fqnEnumType =
EnumType.stringof) = (){
string expandEnum;
foreach(m;__traits(allMembers, EnumType)) {
expandEnum ~= "alias " ~ m ~ " = " ~ fqnEnumType ~ "."
~ m ~ ";";
}
return expandEnum;
}();
```
Then you can mixin aliases for any named enum members you'd
like:
```d
mixin(expandEnum!Colors);
```
It definitely works, thank you.
Re: Colors in Raylib
On Monday, 28 February 2022 at 11:48:59 UTC, Salih Dincer wrote: Is there a namespace I should implement in Raylib? For example, I cannot compile without writing Colors at the beginning of the colors: ```Colors.GRAY``` When writing C bindings, you may refer to this: https://p0nce.github.io/d-idioms/#Porting-from-C-gotchas This keeps example code working.
Re: Colors in Raylib
On Monday, 28 February 2022 at 11:48:59 UTC, Salih Dincer wrote:
Hi All,
Is there a namespace I should implement in Raylib? For example,
I cannot compile without writing Colors at the beginning of the
colors: ```Colors.GRAY```
SDB@79
Assuming you mean the raylib-d binding, it implements the values
as a named enum, so the `Colors` namespace is required.
https://dlang.org/spec/enum.html#named_enums
If you have a situation where you need to type it multiple times
in consecutive code lines, you can use `with`:
```d
with(Colors) {
}
```
Then you can drop the namespace and just used the values. Very
useful for switches:
```d
with(Colors) switch(myColor) {
}
```
You can also generate aliases, so that e.g., `LIGHTGRAY` is
equivalent to `Colors.LIGHTGRAY`). Just throw this template
function in an appropriate module:
```d
enum expandEnum(EnumType, string fqnEnumType = EnumType.stringof)
= (){
string expandEnum;
foreach(m;__traits(allMembers, EnumType)) {
expandEnum ~= "alias " ~ m ~ " = " ~ fqnEnumType ~ "." ~
m ~ ";";
}
return expandEnum;
}();
```
Then you can mixin aliases for any named enum members you'd like:
```d
mixin(expandEnum!Colors);
```
Colors in Raylib
Hi All, Is there a namespace I should implement in Raylib? For example, I cannot compile without writing Colors at the beginning of the colors: ```Colors.GRAY``` SDB@79
Re: https://run.dlang.io/ vs All dmd compilers (2.060 - latest)
On Sunday, 27 February 2022 at 16:14:31 UTC, Matheus wrote: Hi, [...] After one minute I think I get: rdmd playground.d Server error: Thanks, Matheus. This was [reported before]. Apparently this would be caused by a timeout. [reported before]: https://forum.dlang.org/post/skc2dd$1o52$1...@digitalmars.com
Re: Set output location for dub --single
On Sunday, 27 February 2022 at 16:58:34 UTC, Chris Piker wrote: Hi D Coming from a python background it's worked well to organize my D projects as a dub `sourceLibrary` and then to put top level programs in a directory named `scripts` that are just dub single file projects. So the layout looks like this: [...] After reading over the dub documentation I don't see a general way to override project options via the command line, but maybe it's there and I couldn't understand what the dub docs were trying to say. That 's not exactly what you ask for but you can define the path in the embedded recipe (targetPath) ```d #!/usr/bin/env dub /+ dub.sdl: dependency "mypackage" version="*" path=".." targetPath "./bin" +/ ```
