On Tuesday, 23 June 2020 at 21:34:25 UTC, Paul Backus wrote:
If you're open to using Dub packages [...]
Because this is going to be used in almost every program I write,
I need to eliminate outside dependencies as an option.
Nonetheless, thanks for this suggestion.
[2]
On Tuesday, 23 June 2020 at 23:53:36 UTC, claptrap wrote:
So you have opBinary and half a dozen operators to implement.
Do you use a separate method for each operator or do you have
one method and a big static if else if to select code path?
I assume they are functionally equivalent? So its
On Tue, Jun 23, 2020 at 11:53:36PM +, claptrap via Digitalmars-d-learn
wrote:
> So you have opBinary and half a dozen operators to implement. Do you
> use a separate method for each operator or do you have one method and
> a big static if else if to select code path?
[...]
If your
So you have opBinary and half a dozen operators to implement. Do
you use a separate method for each operator or do you have one
method and a big static if else if to select code path?
I assume they are functionally equivalent? So its just about
style?
On Tuesday, 23 June 2020 at 16:14:20 UTC, Denis wrote:
by presenting an interface that only compiles when both cases
are covered, like fun().match((T t) => t, () => Error()).
A complete solution wrapped in a tidy package -- I like it.
Thanks for sharing.
If you're open to using Dub
I'm experimenting with generating wasm files with ldc2 but I'm
having problems when trying to pass JavaScript Objects and
receive them as structs and the other way around.
I found this super nice getting started guide that works fine for
basic types like double and so on
On 6/23/20 9:47 AM, Sebastiaan Koppe wrote:
On Tuesday, 23 June 2020 at 07:30:29 UTC, Stanislav Blinov wrote:
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
I'm also wondering what's the motivation behind supporting
non-copyable ranges, and whether it's worth the effort and
Perhaps this thread would have been better titled "Returning a
value and a status", and the question phrased as "What are your
preferred techniques?".
I'm planning to port some of my programs to D, so I'd like to
standardize on one or two techniques for handling this very
common situation,
On Monday, 22 June 2020 at 20:08:37 UTC, Stanislav Blinov wrote:
But if you'd like it spelled out in text as well, you can make
a PR for the Phobos repository.
Just-Did-It:
https://github.com/dlang/phobos/pull/7540
The point of doc is that the user don't have to dive into the
code to know
On Tuesday, 23 June 2020 at 03:52:23 UTC, Jonathan M Davis wrote:
It is extremely common to wrap ranges in other ranges (and in
fact, you basically have to in order to have lazy ranges). That
really doesn't work very well - if at all - if you can't copy
the range. It might be possible with a
On Tuesday, 23 June 2020 at 07:30:29 UTC, Stanislav Blinov wrote:
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
I'm also wondering what's the motivation behind supporting
non-copyable ranges, and whether it's worth the effort and
inevitable complications to support it if it's a
On 6/23/20 5:15 AM, WebFreak001 wrote:
I have the following code:
double[string] foo;
foo["a"] += 1;
how is the opOpAssign on the AA defined? Is it defined to set the value
to the value to the right of the opOpAssign if it isn't set for
primitives or does it add the given value
On Tuesday, 23 June 2020 at 09:15:57 UTC, WebFreak001 wrote:
[...]
it will give me a range violation at runtime and not init it
for me at all.
There is `aa.require("a", Foo.init) += 4;` now which solves
this, but I would prefer having the small simple syntax well
defined for all types
I have the following code:
double[string] foo;
foo["a"] += 1;
how is the opOpAssign on the AA defined? Is it defined to set the
value to the value to the right of the opOpAssign if it isn't set
for primitives or does it add the given value onto T.init?
Doing
foo["b"]++;
gives
On Tuesday, 23 June 2020 at 02:56:36 UTC, 9il wrote:
Should it always be 53? or it can be 64, when?
Thank you
For LDC, it's 53 (and .sizeof == 8) for MSVC targets, but 64
(x87) for MinGW, reflecting the accompanying C runtime's `long
double`. [And IIRC, MS disallows any x87 usage in kernel
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
On Tue, Jun 23, 2020 at 03:25:55AM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis
wrote:
> We'd need some major redesigning to make uncopyable ranges
> work, and
On Tuesday, 23 June 2020 at 04:01:45 UTC, Denis wrote:
(1) Assign an unused value for the flag (e.g. -1 when the
function returns an int), and return the combined value/flag.
This happens in some Phobos algorithms, and might be the most
common on this list.
(2) Return a tuple with the
On Tuesday, 23 June 2020 at 03:52:23 UTC, Jonathan M Davis wrote:
On Monday, June 22, 2020 9:25:55 PM MDT Stanislav Blinov via
Digitalmars-d- learn wrote:
On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis
wrote:
> As things stand, uncopyable ranges aren't really a thing,
> and common
18 matches
Mail list logo
