On Tuesday, 1 March 2022 at 15:37:55 UTC, Ali Çehreli wrote:
On 3/1/22 07:19, Mike Parker wrote:
> On Tuesday, 1 March 2022 at 13:15:09 UTC, meta wrote:
>
>>
>> enum Color
>> { GRAY }
>>
>> void setColor(Color color);
>>
>> setColor(GRAY);
>
> Then that defeats the purpose of havi
On Monday, 28 February 2022 at 12:18:37 UTC, Mike Parker wrote:
Then you can mixin aliases for any named enum members you'd
like:
```d
mixin(expandEnum!Colors);
```
Meanwhile it's very skillful :)
It is possible to change all the color palette with a second
parameter:
```d
import std.stdio
On 3/1/22 07:19, Mike Parker wrote:
> On Tuesday, 1 March 2022 at 13:15:09 UTC, meta wrote:
>
>>
>> enum Color
>> { GRAY }
>>
>> void setColor(Color color);
>>
>> setColor(GRAY);
>
> Then that defeats the purpose of having named enums.
Yes and no.
meta is pointing at a difference
On Tuesday, 1 March 2022 at 13:15:09 UTC, meta wrote:
enum Color
{ GRAY }
void setColor(Color color);
setColor(GRAY);
Then that defeats the purpose of having named enums.
On Tuesday, 1 March 2022 at 12:29:56 UTC, Steven Schveighoffer
wrote:
On 3/1/22 7:22 AM, meta wrote:
If the type is ``Color`` I think the compiler should allow
``GRAY`` if it is a member of ``Color``, isn't how strong
statically typed language should work? I wonder what is the
rational against
On 3/1/22 7:22 AM, meta wrote:
If the type is ``Color`` I think the compiler should allow ``GRAY`` if
it is a member of ``Color``, isn't how strong statically typed language
should work? I wonder what is the rational against it? How hard would it
be to allow it?
The problem is how the origina
If the type is ``Color`` I think the compiler should allow
``GRAY`` if it is a member of ``Color``, isn't how strong
statically typed language should work? I wonder what is the
rational against it? How hard would it be to allow it?
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 exclu
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 origina
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 ~ ";";
}
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-i
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 th
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
13 matches
Mail list logo
