On Friday, 18 June 2021 at 04:24:19 UTC, jfondren wrote:
On Thursday, 17 June 2021 at 21:41:28 UTC, Steven Schveighoffer
wrote:
A final switch on an enum complains if you don't handle all
the enum's cases. I like this feature.
...
Oh, and to throw a monkey wrench in here, the value is a
string
On Thursday, 17 June 2021 at 21:41:28 UTC, Steven Schveighoffer
wrote:
A final switch on an enum complains if you don't handle all the
enum's cases. I like this feature.
However, sometimes the data I'm switching on is coming from
elsewhere (i.e. a user), and while I want to enforce that the
d
On Thursday, 17 June 2021 at 21:41:28 UTC, Steven Schveighoffer
wrote:
A final switch on an enum complains if you don't handle all the
enum's cases. I like this feature.
...
Oh, and to throw a monkey wrench in here, the value is a
string, not an integer. So I can't use std.conv.to to verify
th
On Thursday, 17 June 2021 at 18:54:41 UTC, WebFreak001 wrote:
On Thursday, 17 June 2021 at 16:26:57 UTC, JG wrote:
[...]
Thanks, this works. I would have thought this would be a
common enough use case to have support in diet. Anyone else
wanted this?
Opened an issue here:
https://github.co
On Thursday, 17 June 2021 at 21:41:28 UTC, Steven Schveighoffer
wrote:
Any ideas on better ways to handle this?
I've had such a situation before too where I want to switch over
enums I read from an ELF file which can't be assumed to be
correct, but I also don't want to forget one. For a tight
On Thu, Jun 17, 2021 at 05:41:28PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[.[..]
> Oh, and to throw a monkey wrench in here, the value is a string, not
> an integer. So I can't use std.conv.to to verify the enum is valid
> (plus, then I'm running a switch twice).
>
> Any ideas
A final switch on an enum complains if you don't handle all the enum's
cases. I like this feature.
However, sometimes the data I'm switching on is coming from elsewhere
(i.e. a user), and while I want to enforce that the data is valid (it's
one of the enum values), I don't want to crash the pr
On 6/17/21 5:01 PM, Ali Çehreli wrote:
What's the difference? In both cases an int is being converted to a Foo.
I think the "working" case is against the design of D.
Likely there is a subtlety that I am missing...
The difference might be that construction has only one set of overloads
--
On 6/17/21 1:46 PM, Steven Schveighoffer wrote:
> Implicit construction is supported:
>
> struct Foo
> {
> int x;
> this(int y) { x = y; }
> }
>
> Foo f = 5; // ok implicit construction
That's so unlike the rest of the language that I consider it to be a
bug. :) Really, why? What if the
On 6/17/21 4:22 PM, kdevel wrote:
On Thursday, 17 June 2021 at 19:14:28 UTC, Steven Schveighoffer wrote:
On 6/17/21 12:26 PM, JG wrote:
However, what I *have* wanted is to have attribute values support
`Nullable!T` such that they are only included if the item is non-null.
See [here](https://g
On 6/17/21 4:15 PM, H. S. Teoh wrote:
On Thu, Jun 17, 2021 at 07:44:31PM +, JN via Digitalmars-d-learn wrote:
[...]
Foo[int] foos = [
0: Foo("abc"),
1: Foo(5)
];
}
```
Why does D need the explicit declarations whereas C++ can infer it?
Because D does not suppor
On Thursday, 17 June 2021 at 19:14:28 UTC, Steven Schveighoffer
wrote:
On 6/17/21 12:26 PM, JG wrote:
However, what I *have* wanted is to have attribute values
support `Nullable!T` such that they are only included if the
item is non-null. See
[here](https://github.com/rejectedsoftware/diet-ng
On Thu, Jun 17, 2021 at 07:44:31PM +, JN via Digitalmars-d-learn wrote:
[...]
> Foo[int] foos = [
> 0: Foo("abc"),
> 1: Foo(5)
> ];
> }
> ```
>
> Why does D need the explicit declarations whereas C++ can infer it?
Because D does not support implicit construction. The a
This C++ code compiles:
```cpp
#include
#include
#include
int main()
{
using Foo = std::variant;
std::map foos = {{0, "abc"}, {1, 5}};
}
This code doesn't:
```d
import std.variant;
void main()
{
alias Foo = Algebraic!(int, string);
Foo[int] foos = [
0: "abc",
On 6/17/21 12:26 PM, JG wrote:
Thanks, this works. I would have thought this would be a common enough
use case to have support in diet. Anyone else wanted this?
I haven't found a need for it, as I'm usually only dynamically
configuring attribute values, not attribute names. But my web-fu is
On Thursday, 17 June 2021 at 16:26:57 UTC, JG wrote:
[...]
Thanks, this works. I would have thought this would be a common
enough use case to have support in diet. Anyone else wanted
this?
Opened an issue here:
https://github.com/rejectedsoftware/diet-ng/issues/91
On 6/17/21 9:10 AM, Justin Choi wrote:
>> DList!(int[])() ?
>
> Thanks I've mentally slapped myself a hundred times for this mistake :D
Also, unless DList is really needed, why not:
int[][]
Ali
On Thursday, 17 June 2021 at 09:16:56 UTC, WebFreak001 wrote:
On Thursday, 17 June 2021 at 08:23:54 UTC, JG wrote:
Suppose I have an array of attributes and values v is there
any way to apply these attributes to a tag?
So that something like
tag(#{v[0]0]}=#{v[0][1]},...})
becomes
where v[
On Thursday, 17 June 2021 at 15:58:40 UTC, Adam D Ruppe wrote:
On Thursday, 17 June 2021 at 15:57:46 UTC, Justin Choi wrote:
I want to write something like `DList!int[]()`
DList!(int[])() ?
Thanks I've mentally slapped myself a hundred times for this
mistake :D
If I wanted to create a DList (or any similar data structure) of
multiple integers, how would I accomplish this?
I want to write something like `DList!int[]()` but the best I can
do for now is a format such as `DList!(Tuple(int, int))()` which
confines me to a fixed number of integers.
On Thursday, 17 June 2021 at 15:57:46 UTC, Justin Choi wrote:
I want to write something like `DList!int[]()`
DList!(int[])() ?
On Thursday, 17 June 2021 at 08:23:54 UTC, JG wrote:
Suppose I have an array of attributes and values v is there any
way to apply these attributes to a tag?
So that something like
tag(#{v[0]0]}=#{v[0][1]},...})
becomes
where v[0][0]="attribute0" and v[0][1]="value0"?
I think there is not
Suppose I have an array of attributes and values v is there any
way to apply these attributes to a tag?
So that something like
tag(#{v[0]0]}=#{v[0][1]},...})
becomes
where v[0][0]="attribute0" and v[0][1]="value0"?
On Wednesday, 16 June 2021 at 23:20:26 UTC, Ali Çehreli wrote:
Thank you, both. It still rules out an address at "compile
time" in general. For example, we cannot use such an address
when instantiating a template, or static array length, etc.
And if I understand it correctly, there must be a p
24 matches
Mail list logo
