3.to!string;
writeln (w);
long l = 3.to!long;
writeln (l);
}
```
I ended up adding
```d
V to (V, T) (T t)
{
static import std.conv;
return std.conv.to!V (t);
}
V to (V : vstring, T) (T t)
{
static import std.conv;
auto s = std.conv.to!(TypedefType!V) (t);
return cast
ln (l);
}
```
I ended up adding
```d
V to (V, T) (T t)
{
static import std.conv;
return std.conv.to!V (t);
}
V to (V : vstring, T) (T t)
{
static import std.conv;
auto s = std.conv.to!(TypedefType!V) (t);
return cast (V) s;
}
```
to the code. Is there a way to add only a pa
On Sunday, 8 January 2023 at 12:39:37 UTC, thebluepandabear wrote:
...
The `foreach` worked for that case since `bark` is a method of
`IDog`. `update` is not so a conversion to `Button[]` is needed.
In that case, you could do a casting like this:
import std.stdio, std.conv;
interface IDog
On Sunday, 8 January 2023 at 11:29:10 UTC, thebluepandabear wrote:
...
There is an explanation here:
https://forum.dlang.org/post/tqukutfzeaxedunuv...@forum.dlang.org
But in any case I'd like to point it out that I think you could
do that foreach without casting or std.conv by just omitting
On Sunday, 8 January 2023 at 12:35:38 UTC, matheus wrote:
On Sunday, 8 January 2023 at 11:29:10 UTC, thebluepandabear
wrote:
...
There is an explanation here:
https://forum.dlang.org/post/tqukutfzeaxedunuv...@forum.dlang.org
But in any case I'd like to point it out that I think you could
d
On 08.01.23 12:29, thebluepandabear wrote:
```D
interface ICustomDrawable {
void render(sfRenderWindow* renderWindow);
}
[...]> class Button : ICustomDrawable {
[...]
}
[...]
class StackLayout : ICustomDrawable {
[...]
ICustomDrawable[] _children;
}
```
For some reason, when I wa
I've been writing some code and I have been experimenting with
casting. I've found that sometimes only `std.conv.to!` does the
job over casting, and I am unsure why this is the case as I
assumed that they are both the same.
I have the following interface:
```D
interface ICust
On 6/17/22 8:48 AM, harakim wrote:
On Friday, 17 June 2022 at 12:31:45 UTC, harakim wrote:
I can generically convert a string to a type using to!type. I have a
read function that does that. I have simplified the example below:
```d
int readNumber()
{
return read!int(val => to!i
On Friday, 17 June 2022 at 18:40:59 UTC, Ali Çehreli wrote:
On 6/17/22 10:04, Salih Dincer wrote:
> Isn't foo and bar the same thing? I don't understand what's
the
> difference!
> ```d
>auto foo = to!Foo("123"); //??
>auto bar = Foo("321");
> ```
Yes, they are the same thing.
But (!)
c way of converting any type to any other
type as long as there is a way. (Think a function template.) std.conv.to
can do that because it considers the constructors as well.
Ali
On Friday, 17 June 2022 at 12:53:53 UTC, bauss wrote:
Just add a constructor to your type that takes the value of
what you want to convert.
Working example:
```d
struct Foo
{
int value;
this(int v)
{
value = v;
}
this(string v)
{
this(to!int(v));
}
On Friday, 17 June 2022 at 12:53:53 UTC, bauss wrote:
Just add a constructor to your type that takes the value of
what you want to convert.
Isn't foo and bar the same thing? I don't understand what's the
difference! By the way, what's the question? Is this the answer
to the question?
`
On Friday, 17 June 2022 at 12:48:56 UTC, harakim wrote:
On Friday, 17 June 2022 at 12:31:45 UTC, harakim wrote:
I can generically convert a string to a type using to!type. I
have a read function that does that. I have simplified the
example below:
```d
int readNumber()
{
On Friday, 17 June 2022 at 12:31:45 UTC, harakim wrote:
I can generically convert a string to a type using to!type. I
have a read function that does that. I have simplified the
example below:
```d
int readNumber()
{
return read!int(val => to!int(val), "number");
I can generically convert a string to a type using to!type. I
have a read function that does that. I have simplified the
example below:
```d
int readNumber()
{
return read!int(val => to!int(val), "number");
}
string readTime()
{
On Friday, 15 November 2019 at 04:26:58 UTC, Jon Degenhardt wrote:
On Friday, 15 November 2019 at 03:51:04 UTC, Joel wrote:
I made a feature that converts, say, [9:59am] -> [10:00am] to
1 minute. but found '9'.to!int = 57 (not 9).
Doesn't seem right... I'm guessing that's standard though,
sam
On Friday, 15 November 2019 at 03:51:04 UTC, Joel wrote:
I made a feature that converts, say, [9:59am] -> [10:00am] to 1
minute. but found '9'.to!int = 57 (not 9).
Doesn't seem right... I'm guessing that's standard though, same
with ldc.
Use a string or char[] array. e.g. writeln("9".to!int)
I made a feature that converts, say, [9:59am] -> [10:00am] to 1
minute. but found '9'.to!int = 57 (not 9).
Doesn't seem right... I'm guessing that's standard though, same
with ldc.
On Wednesday, 15 August 2018 at 10:38:23 UTC, Jonathan M Davis
wrote:
Would it be sane to add these to std.conv alongside existing
std.conv.to so that underlying logic in std.conv.to can be
reused?
If so, AFAICT, existing std.conv.to should be implemented on
Put something together to get
On Wednesday, 15 August 2018 at 09:26:26 UTC, Seb wrote:
If so, AFAICT, existing std.conv.to should be implemented on
top of std.conv.tryTo.
Well, for now you can use `ifThrown` from std.exception:
https://dlang.org/phobos/std_exception.html#ifThrown
---
"foo".to!int.ifThrown(42)
On Wednesday, August 15, 2018 3:21:29 AM MDT Per Nordlöw via Digitalmars-d-
learn wrote:
> Have anybody thought about non-throwing variants of std.conv.to
> typically named `tryTo`
> similar to what Folly
>
> https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#
On Wednesday, 15 August 2018 at 09:21:29 UTC, Per Nordlöw wrote:
Have anybody thought about non-throwing variants of std.conv.to
typically named `tryTo`
similar to what Folly
https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throwing-interfaces
does, for instance, as
Have anybody thought about non-throwing variants of std.conv.to
typically named `tryTo`
similar to what Folly
https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throwing-interfaces
does, for instance, as
tryTo(str).then([](int i) { use(i); });
?
Would it be sane to add
== enum))
{
// doesn't need `std.conv.to`
switch (value)
{
static foreach (member; __traits(allMembers, T)) //
prevents call to slower `EnumMembers`
{
case member:
return __traits(getMember, T, member); // NOTE this
is slower: mixin(`return T.` ~ m
On Wednesday, 20 June 2018 at 09:54:29 UTC, Per Nordlöw wrote:
T toDefaulted(T)(scope const(char)[] value,
T defaultValue) @safe pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
static foreach (index, member; __traits(allMembers, T))
{
case
On Wednesday, June 20, 2018 09:37:00 Per Nordlöw via Digitalmars-d-learn
wrote:
> On Wednesday, 20 June 2018 at 09:27:14 UTC, Per Nordlöw wrote:
> > On Monday, 18 June 2018 at 21:10:03 UTC, Steven Schveighoffer
> >
> > wrote:
> >> It just means re-doing std.conv.
On Wednesday, 20 June 2018 at 09:37:00 UTC, Per Nordlöw wrote:
AFAICT, string-to-enum-conversion must include a switch
containing a static foreach over all the enumerators, right?
My suggestion for nothrow @nogc string-to-enum conversion with
default value
T toDefaulted(T)(scope const(char)
On Wednesday, 20 June 2018 at 09:52:04 UTC, Per Nordlöw wrote:
My suggestion for nothrow @nogc string-to-enum conversion with
default value
T toDefaulted(T)(scope const(char)[] value,
T defaultValue) @safe pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
On Wednesday, 20 June 2018 at 09:27:14 UTC, Per Nordlöw wrote:
On Monday, 18 June 2018 at 21:10:03 UTC, Steven Schveighoffer
wrote:
It just means re-doing std.conv.to, which is pretty hairy, but
also pretty well-organized.
Ok. Where in std.conv do the string-to-enum conversions take
place
On Monday, 18 June 2018 at 21:10:03 UTC, Steven Schveighoffer
wrote:
It just means re-doing std.conv.to, which is pretty hairy, but
also pretty well-organized.
Ok. Where in std.conv do the string-to-enum conversions take
place?
that and throw or use default
value based on the return value.
It just means re-doing std.conv.to, which is pretty hairy, but also
pretty well-organized.
-Steve
On Monday, 18 June 2018 at 20:48:55 UTC, Per Nordlöw wrote:
T toDefaulted(T, S, U)(S value, /*lazy*/ U defaultValue)
if (is(typeof(() { T r = defaultValue; }))) // TODO use
std.traits.isAssignable!(T, U) ?
why not just make it
T toDefaulted(T, S)(S value, T defaultValue)
and forget U entirel
I have a nothrow variant of std.conv.to defined as follows:
T toDefaulted(T, S, U)(S value, /*lazy*/ U defaultValue)
if (is(typeof(() { T r = defaultValue; }))) // TODO use
std.traits.isAssignable!(T, U) ?
{
try
{
import std.conv : to;
return value.to!T;
}
catch
Thank you, core.runtime.Runtime.initialize() fixed the issue. I
am now able to use to!string as well. I found your posts and Ali
Çehreli's posts on this subject. I think I have some
understanding now.
On Saturday, 9 December 2017 at 06:14:36 UTC, Venkat wrote:
Thanks for the quick response. std.string.fromStringz did the
trick. I am not sure what was the deal with to!string.
Be careful with fromStringz. It doesn't allocate a new string, so
the returned string can easily become corrupted if
Thanks for the quick response. std.string.fromStringz did the
trick. I am not sure what was the deal with to!string.
On Saturday, 9 December 2017 at 05:55:21 UTC, Venkat wrote:
I am trying out the DJni library
(https://github.com/Monnoroch/DJni). For some reason
std.conv.to!string doesn't want to convert a char* to a
string.The lines below are taken from the log. I see that the
last frame is at gc_qall
I am trying out the DJni library
(https://github.com/Monnoroch/DJni). For some reason
std.conv.to!string doesn't want to convert a char* to a
string.The lines below are taken from the log. I see that the
last frame is at gc_qalloc. I am not sure why it failed there.
Can anybody elabora
On Monday, 11 January 2016 at 12:59:05 UTC, Tobi G. wrote:
On Monday, 11 January 2016 at 12:15:55 UTC, Saurabh Das wrote:
Any ideas?
Yes. Because Typedef is introducing new Types, which csvReader
doesn't know what they are,
you'll need a little workaround and cast the values yourself.
impo
On Monday, 11 January 2016 at 12:15:55 UTC, Saurabh Das wrote:
Any ideas?
Yes. Because Typedef is introducing new Types, which csvReader
doesn't know what they are,
you'll need a little workaround and cast the values yourself.
import std.csv, std.stdio, std.algorithm, std.range;
enum csvTx
On Monday, 11 January 2016 at 12:01:30 UTC, Tobi G. wrote:
On Monday, 11 January 2016 at 08:03:19 UTC, Saurabh Das wrote:
How can I get std.conv to understand std.typecons.Typedef?
You can do something like this:
QuestionId q = to!(TypedefType!QuestionId)("43");
In general, is there a bette
On Monday, 11 January 2016 at 08:03:19 UTC, Saurabh Das wrote:
How can I get std.conv to understand std.typecons.Typedef?
You can do something like this:
QuestionId q = to!(TypedefType!QuestionId)("43");
In general, is there a better solution to orthogonal types than
Typedef?
Typedef is a
wever I'm failing to use using std.conv.to:
QuestionId q = to!QuestionId("34"); <-- gives compile errors
(This is a reduced example, the actual use case is to use std.csv
to read in a structure from file, which in turn calls to!xyz)
How can I get std.conv to understand std.typ
On Saturday, 14 November 2015 at 18:52:54 UTC, anonymous wrote:
On 14.11.2015 15:40, Relja wrote:
[...]
Alright, full test case:
import std.conv;
[...]
Great explanation! Thank you!
On 14.11.2015 15:40, Relja wrote:
float[3] array;
array.to!string; // compiles
Alright, full test case:
import std.conv;
float[3] getFloat3() {
return [1, 2, 3];
}
void main() {
getFloat3().to!string; // does not compile
float[3] a;
a.to!string; // compiles
}
Yeah,
On Saturday, 14 November 2015 at 14:30:06 UTC, anonymous wrote:
On 14.11.2015 15:17, Relja wrote:
- std.conv.to!string() works on a static array, when called
directly on
the array object, but gives the compile error when called on
the
returning object from a function.
[...]
void main
On 14.11.2015 15:17, Relja wrote:
- std.conv.to!string() works on a static array, when called directly on
the array object, but gives the compile error when called on the
returning object from a function.
[...]
void main() {
getFloat3().to!string; // does not compile
(new float[3
On Saturday, 14 November 2015 at 12:55:52 UTC, BBaz wrote:
On Saturday, 14 November 2015 at 12:46:21 UTC, Relja wrote:
I've got this strange compile error using
std.conv.to!string(double[3]) - or any static array type. It's
called in toString override function of a template matrix
On Saturday, 14 November 2015 at 12:46:21 UTC, Relja wrote:
I've got this strange compile error using
std.conv.to!string(double[3]) - or any static array type. It's
called in toString override function of a template matrix
class, I'm building as a D learning project.
[...]
M
I've got this strange compile error using
std.conv.to!string(double[3]) - or any static array type. It's
called in toString override function of a template matrix class,
I'm building as a D learning project.
Here is the toString method:
override string toString() const
{
On Tuesday, 13 October 2015 at 22:21:43 UTC, Ali Çehreli wrote:
Reduced with a workaround:
struct UTCOffset
{
import std.conv : to;// Move to module scope to compile
This introduces UTCOffset.to as an alias to std.conv.to.
string toString() const
{
return "
, you might try moving that @property:
to after toString and see if that fixes your problem. But given
the error, my guess is that the problem relates to the fact
that you templatized the constructor, which is often
problematic, and whatever type introspection std.conv.to is
doing could be choking o
On 10/13/2015 02:07 PM, Nordlöw wrote:
I have defined a struct UTCOffset in
https://github.com/nordlow/justd/blob/master/datetime_ex.d
Everything works as desired except for
import std.conv : to;
assert(UTCOffset(+14, 0).to!string == "UTC+14:00");
which fails as
/usr/include/dmd/ph
#x27;s
not called with parens, then that code won't work. So, you might try moving
that @property: to after toString and see if that fixes your problem. But
given the error, my guess is that the problem relates to the fact that you
templatized the constructor, which is often problematic, and whatever t
I have defined a struct UTCOffset in
https://github.com/nordlow/justd/blob/master/datetime_ex.d
Everything works as desired except for
import std.conv : to;
assert(UTCOffset(+14, 0).to!string == "UTC+14:00");
which fails as
/usr/include/dmd/phobos/std/conv.d(293,14): Error: template
On Sunday, 27 September 2015 at 05:52:26 UTC, Jack Stouffer wrote:
Please make an issue on https://issues.dlang.org and I'll take
a look a this later. Most of the functions in std.conv are
templated so it must be some internal function that's not
properly annotated, or it's using manual memory
On 27/09/2015 3:14 AM, cym13 wrote:
On Saturday, 26 September 2015 at 17:08:00 UTC, Nordlöw wrote:
Why is the following code not pure:
float x = 3.14;
import std.conv : to;
auto y = x.to!string;
???
Is there a reason for it not being pure? If not, this is a serious
problem as thi
On Saturday, 26 September 2015 at 17:08:00 UTC, Nordlöw wrote:
Why is the following code not pure:
float x = 3.14;
import std.conv : to;
auto y = x.to!string;
???
Is there a reason for it not being pure? If not, this is a
serious problem as this is such a fundamental function.
On Saturday, 26 September 2015 at 17:08:00 UTC, Nordlöw wrote:
Why is the following code not pure:
float x = 3.14;
import std.conv : to;
auto y = x.to!string;
???
Is there a reason for it not being pure? If not, this is a
serious problem as this is such a fundamental function.
On Saturday, 26 September 2015 at 17:08:00 UTC, Nordlöw wrote:
Why is the following code not pure:
float x = 3.14;
import std.conv : to;
auto y = x.to!string;
???
Is there a reason for it not being pure? If not, this is a
serious problem as this is such a fundamental function.
Why is the following code not pure:
float x = 3.14;
import std.conv : to;
auto y = x.to!string;
???
Is there a reason for it not being pure? If not, this is a
serious problem as this is such a fundamental function.
On Wednesday, 29 April 2015 at 14:46:04 UTC, Per Nordlöw wrote:
On Tuesday, 28 April 2015 at 23:09:27 UTC, Per Nordlöw wrote:
On Tuesday, 28 April 2015 at 16:20:24 UTC, Per Nordlöw wrote:
I update my Github repo. I had forgotten to push my latest
changes.
I solved it.
I started working on
On Tuesday, 28 April 2015 at 23:09:27 UTC, Per Nordlöw wrote:
On Tuesday, 28 April 2015 at 16:20:24 UTC, Per Nordlöw wrote:
I update my Github repo. I had forgotten to push my latest
changes.
I solved it.
On Tuesday, 28 April 2015 at 16:20:24 UTC, Per Nordlöw wrote:
I update my Github repo. I had forgotten to push my latest
changes.
At
https://github.com/nordlow/justd/blob/master/conv_ex.d
I'm trying to figure out how to best implement a fuzzy variant of
std.conv.to when converting a string to an enum.
I'm almost there but I'm uncertain how to best pick the index of
the smallest element in `distances` a
On Sunday, 22 February 2015 at 13:15:31 UTC, Adam D. Ruppe wrote:
to!string actually forwards to a special function, "string
toString() {}" which you'll need to implement and override from
the base class.
Thanks, that's good to know.
I was just wondering why my code wasn't working correctly.
On Sunday, 22 February 2015 at 13:04:56 UTC, Jacques Müller wrote:
I tried to override the opCast operator in a class to be able
to explicitly convert the class to a string, but to!string just
returns the name of the class.
to!string actually forwards to a special function, "string
toString()
I tried to override the opCast operator in a class to be able to
explicitly convert the class to a string, but to!string just
returns the name of the class.
Do opCast and to! together not work with strings and does that
mean that i have to use alias this?
While snprintf might be one thing that provides to be an interesting
obstacle, the better answer to why std.conv.to isnt pure is that no one
has invested the time to work through issues like that to make it so.
It _should_ be pure.
On 2/14/2015 12:32 PM, ketmar via Digitalmars-d-learn wrote
On Sat, 14 Feb 2015 19:59:58 +, Gary Willoughby wrote:
> On Saturday, 14 February 2015 at 12:24:51 UTC, ketmar wrote:
>> On Sat, 14 Feb 2015 11:29:28 +, Jack Applegame wrote:
>>
>>> why std.conv.to is not pure?
>>>
>>> string foo(real v) pure
On Saturday, 14 February 2015 at 12:24:51 UTC, ketmar wrote:
On Sat, 14 Feb 2015 11:29:28 +, Jack Applegame wrote:
why std.conv.to is not pure?
string foo(real v) pure { return v.to!string; }
// Error: pure function 'foo' cannot call impure function
'std.conv.to!stri
On Sat, 14 Feb 2015 11:29:28 +, Jack Applegame wrote:
> why std.conv.to is not pure?
>
> string foo(real v) pure { return v.to!string; }
> // Error: pure function 'foo' cannot call impure function
> 'std.conv.to!string.to!(real).to'
'cause float-&g
why std.conv.to is not pure?
string foo(real v) pure { return v.to!string; }
// Error: pure function 'foo' cannot call impure function
'std.conv.to!string.to!(real).to'
On Thursday, 4 July 2013 at 16:16:08 UTC, Ali Çehreli wrote:
On 07/04/2013 03:15 AM, Joseph Rushton Wakeling wrote:
> The cast should be safe, as it's a size_t to a double.
I am commenting without fully understanding the context: Both
size_t and double are 64 bit types on a 64-bit system.
dou
On Thu, Jul 04, 2013 at 06:43:16PM +0200, Joseph Rushton Wakeling wrote:
> On 07/04/2013 06:16 PM, Ali Çehreli wrote:
> > I am commenting without fully understanding the context: Both size_t
> > and double are 64 bit types on a 64-bit system. double.mant_dig
> > being 53, converting from size_t to
On 07/04/2013 09:43 AM, Joseph Rushton Wakeling wrote:
> On 07/04/2013 06:16 PM, Ali Çehreli wrote:
>> I am commenting without fully understanding the context: Both size_t
and double
>> are 64 bit types on a 64-bit system. double.mant_dig being 53,
converting from
>> size_t to double loses inf
On 07/04/2013 06:16 PM, Ali Çehreli wrote:
> I am commenting without fully understanding the context: Both size_t and
> double
> are 64 bit types on a 64-bit system. double.mant_dig being 53, converting from
> size_t to double loses information for many values.
Oh, bugger. You mean that because
On 07/04/2013 03:15 AM, Joseph Rushton Wakeling wrote:
> The cast should be safe, as it's a size_t to a double.
I am commenting without fully understanding the context: Both size_t and
double are 64 bit types on a 64-bit system. double.mant_dig being 53,
converting from size_t to double loses
By the way, CJS -- sorry to have hijacked your query. But I
think you had your answer already :-)
Yes. It was a very helpful answer. I'm just glad the question I
asked was apparently relevant to other users as well.
On Thursday, 4 July 2013 at 10:23:22 UTC, monarch_dodra wrote:
I'm trying to read the bug entry, but I don't get it. Maybe a
reduced case to explain?
Point is, the skip() function in std.random.RandomSample can be
called with the floating-point variable _Vprime equal to nan,
_if_ popFront() o
On Thursday, 4 July 2013 at 10:32:26 UTC, Joseph Rushton Wakeling
wrote:
I can prepare a reduced example but it's probably simpler for
me to just prepare a bugfix and do some benchmarks.
By the way, CJS -- sorry to have hijacked your query. But I
think you had your answer already :-)
On Thursday, 4 July 2013 at 10:15:22 UTC, Joseph Rushton Wakeling
wrote:
On 07/04/2013 12:08 PM, monarch_dodra wrote:
I didn't go into the details, but in your bug report, it seems
like it is more
of an implementation error ? In that case, an ERROR would be
better.
The cast should be safe, as
On 07/04/2013 12:08 PM, monarch_dodra wrote:
> I didn't go into the details, but in your bug report, it seems like it is more
> of an implementation error ? In that case, an ERROR would be better.
The cast should be safe, as it's a size_t to a double. It's just that having
to!double() would have
On Thursday, 4 July 2013 at 09:31:42 UTC, Joseph Rushton Wakeling
wrote:
On 07/04/2013 10:14 AM, monarch_dodra wrote:
Casting merely changes the "observed type", whereas "to" does
a deep conversion.
What are the speed implications of to compared to cast?
I ask because I see various casts in P
On 07/04/2013 10:14 AM, monarch_dodra wrote:
> Casting merely changes the "observed type", whereas "to" does a deep
> conversion.
What are the speed implications of to compared to cast?
I ask because I see various casts in Phobos, and wonder if there isn't improved
safety in preferring instead t
On Thursday, 4 July 2013 at 06:18:21 UTC, CJS wrote:
I'm having trouble understanding the difference between casting
and std.conv.to. Any help?
Casting merely changes the "observed type", whereas "to" does a
deep conversion.
Observe:
import std.stdio;
im
I'm having trouble understanding the difference between casting
and std.conv.to. Any help?
It can't implicitly convert an int to a bool. The C function returns an int.
Andrej Mitrovic Wrote:
> Wow not a minute later and I get bitten by my own solution. A C
> function returned 1 for a supported feature, and -1 otherwise. And of
> course -1 got converted to true, so then I had a bug in my code.
>
> Damn silly C functions which return -1 when they should return 0.
Wow not a minute later and I get bitten by my own solution. A C
function returned 1 for a supported feature, and -1 otherwise. And of
course -1 got converted to true, so then I had a bug in my code.
Damn silly C functions which return -1 when they should return 0.
Or damn me for not RTFM'ing.
eChar!(ElementType!(S))) cannot deduce
template function from argument types !(bool)(uint)
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(99): Error: template
instance errors instantiating template
boolConv.d(9): Error: template instance std.conv.to!(bool).to!(uint) error
instantiating
Wh
91 matches
Mail list logo
