SumType is a generic sum type for modern D. It is meant as an
alternative to `std.variant.Algebraic`.
Features:
- Pattern matching, including support for structural matching
(*)
- Self-referential types, using `This`
- Works with `pure`, `@safe`, `@nogc`, and `immutable` (*)
- Zero
On Monday, 7 May 2018 at 09:23:04 UTC, Brian Schott wrote:
I spent several hours trying to get this working with a
non-trivial AST, and I think that it just isn't going to work
until the compiler front-end gets better about handling
recursive definitions. It fails in more-or-less the same way
On Tuesday, 8 May 2018 at 06:33:38 UTC, TheGag96 wrote:
Wow.. without comments and unittests, the implementation is
only 116 lines. Awesome job. Even now I still find it
incredible what D can do. Is Algebraic in the standard library
really that bad? And if so, why aren't implementations like
On Monday, 7 May 2018 at 19:28:16 UTC, Sönke Ludwig wrote:
Another similar project: http://taggedalgebraic.dub.pm/
There's also tagged_union and minivariant on dub, that I've
found. I'm definitely far from the first person to be
dissatisfied with `Algebraic`, or to try my hand at writing a
On Wednesday, 9 May 2018 at 13:33:44 UTC, jmh530 wrote:
On Sunday, 6 May 2018 at 19:18:02 UTC, Paul Backus wrote:
[snip]
- Zero runtime overhead compared to hand-written C
Just to clarify, would the run-time performance of the length
function in the example be equivalent to if it had been
On Monday, 21 May 2018 at 14:48:23 UTC, Mike Parker wrote:
Nick Sabaluasky's first post to the D Blog is a tip on how to
create an aliased type that keeps its name in error messages.
I'm not sure making `_data` private is really a good idea. For
example, this only works if `_data` is public:
SumType is a generic sum type for modern D. It is meant as an
alternative to `std.variant.Algebraic`.
Features:
- Pattern matching, including support for structural matching
(*)
- Self-referential types, using `This`
- Works with `pure`, `@safe`, `@nogc`, and `immutable` (*)
- Zero
On Thursday, 9 August 2018 at 00:11:22 UTC, Seb wrote:
On Thursday, 9 August 2018 at 00:07:05 UTC, Seb wrote:
(It uses the version from DUB and updates itself once daily,
but somehow dub still lists 0.4.1 at the moment)
It looks like you didn't push the git tag to GitHub:
On Wednesday, 8 August 2018 at 21:57:07 UTC, vit wrote:
Nice,
but destructor SumType.~this() can call destroy on reference
type like class:
Whoops. Good catch. I've pushed a fix, tagged as version 0.5.1.
On Friday, 10 August 2018 at 13:11:13 UTC, Everlast wrote:
On Friday, 10 August 2018 at 12:35:18 UTC, Everlast wrote:
It would be nice if some actual examples could be given. The
help on dub is a bit confusing because the the code is not
complete.
In addition to the example on the dub
On Thursday, 9 August 2018 at 07:52:12 UTC, vit wrote:
SumType without initialization doesn't fail if first type has
@disabled this().
It did fail for me, but it also failed *with* initialization too,
so there was definitely a bug there.
method toString is not template. (why is there in the
On Wednesday, 8 August 2018 at 20:54:13 UTC, Paul Backus wrote:
SumType is a generic sum type for modern D. It is meant as an
alternative to `std.variant.Algebraic`.
Version 0.5.2, with fixes for the bugs reported in this thread,
is now available. Thanks to vit for their detailed feedback!
On Friday, 10 August 2018 at 21:28:40 UTC, Everlast wrote:
Yes, but
alias Z = SumType.Union(X,Y);
is not the same as
alias Z = SumType!(int, float, string, complex, vector).
In the first case Z is actually a union of 2 types while in the
second it is of 5. There is a subtle difference
On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
Hi
See: https://optional.dub.pm
Looks great!
auto john = some(new Person());
Would it also work to leave off the `some` here and skip the
first `dispatch` in the following lines? (i.e., make `john` a
`Person` rather than an
On Friday, 24 August 2018 at 20:59:34 UTC, aliak wrote:
THis is true. And might be interesting to try out actually. Can
you access the types in a SumType via index?
I'm thinking because Optional behaves like a range, and I guess
I'd define a SumType!(T, None), then a rough outline may be:
On Wednesday, 22 August 2018 at 22:11:05 UTC, aliak wrote:
On Monday, 20 August 2018 at 19:52:53 UTC, jmh530 wrote:
It's interesting that both sumtype and optional have match
templates. Maybe scope to combine these projects?
That'd be cool. Optional uses .match on a "some" or "none"
range,
On Wednesday, 8 August 2018 at 20:54:13 UTC, Paul Backus wrote:
SumType is a generic sum type for modern D. It is meant as an
alternative to `std.variant.Algebraic`.
New point release, 0.5.3, with the following updates:
- SumType now uses the smallest possible integer type for its tag
(e.g.,
expectations is an error-handling library that lets you bundle
exceptions together with return values. It is based on Rust's
Result [1] and C++'s proposed std::expected. [2] If you're
not familiar with those, Andrei's NDC Oslo talk, "Expect the
Expected" [3], explains the advantages of this
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote:
expectations is an error-handling library that lets you bundle
exceptions together with return values. It is based on Rust's
Result [1] and C++'s proposed std::expected. [2] If
you're not familiar with those, Andrei's NDC Oslo
On Tuesday, 4 September 2018 at 22:08:48 UTC, Nick Sabalausky
(Abscissa) wrote:
I think you may be getting hung up on a certain particular
detail of Vladimir's exact "draft" implementation of Success,
whereas I'm focusing more on Success's more general point of
"Once the object is no longer
On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity
wrote:
ok. Now, what are your options then (assuming you want an
independent type)?
(option 1) define one encapsulated type, per module.
(option 2) have a means for type independence within a module -
i.e. selective hiding.
D
On Sunday, 30 September 2018 at 22:17:05 UTC, aliak wrote:
On Saturday, 29 September 2018 at 19:27:29 UTC, Paul Backus
wrote:
I agree that this is useful, but why not just return a naked
`SumType!(string, JSONError)` in that case? Is there some
additional value added by the `Expect` wrapper
On Saturday, 29 September 2018 at 12:40:14 UTC, aliak wrote:
I.e. by allowing you to define the unexepcted you could for
instance:
enum JSONError {
invalidKey, notString, notNumber
}
auto a = parse(jsonData);
a.getAsString("key").match!(
(string value) => // yay
(JSONError error)
On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky
(Abscissa) wrote:
Note that the above has *nothing* to do with retrieving a
value. Retrieving a value is merely used by the implementation
as a trigger to lazily decide whether the caller wants `foo` or
`tryFoo`. Going out of scope
On Sunday, 2 September 2018 at 23:38:41 UTC, Per Nordlöw wrote:
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote:
expectations is an error-handling library that lets you bundle
exceptions together with return values. It is based on Rust's
Result [1] and C++'s proposed
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev
wrote:
Please correct me if I'm wrong, but from looking at the code,
given e.g.:
Expected!void copyFile(string from, string to);
nothing prevents me from writing:
void main() { copyFile("nonexistent", "target"); }
The success
On Monday, 3 September 2018 at 21:55:57 UTC, Nick Sabalausky
(Abscissa) wrote:
By contrast, a function that returns an `Expected!T` does
*not* force its caller to acknowledge it. If an error occurs,
and the caller never checks value or hasValue...nothing
happens.
That's called squelching an
On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:
Hi,
[...]
Lots of good stuff here!
I'm curious about your approach to `Expect`, since I've written a
version of it myself. How useful have you found being able to use
unexpected values of any type, as opposed to just exceptions?
On Thursday, 17 January 2019 at 16:06:39 UTC, bpr wrote:
On Thursday, 17 January 2019 at 01:59:29 UTC, Walter Bright
wrote:
Bartosz Milewski is a C++ programmer and a Haskell fan. He
once gave a presentation at NWCPP where he wrote a few lines
of Haskell code. Then, he showed the same code
On Friday, 18 January 2019 at 20:03:48 UTC, Mark wrote:
[...]
Represent types as strings, CTFE them as you see fit, and
output a string that can then be mixin'ed to use the actual
type. :)
Two problems:
1) Mixing in a string is unhygienic. If two modules (or two
scopes in the same module)
On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote:
Is it possible to declare a function whose name is a CTFE
computed string?
Yes, if you do it with a string mixin.
On Tuesday, 15 January 2019 at 05:18:45 UTC, aliak wrote:
Quote from article:
"The languages with the strongest positive coefficients -
meaning associated with a greater number of defect fixes are
C++, C, and Objective-C, also PHP and Python. On the other
hand, Clojure, Haskell, Ruby and
On Saturday, 19 January 2019 at 22:07:47 UTC, Ron Tarrant wrote:
On Friday, 18 January 2019 at 18:59:59 UTC, JN wrote:
Just add a line in your dub.json file and you have the
library. Need to upgrade to newer version? Just change the
version in dub.json file. Need to download the problem from
On Wednesday, 12 December 2018 at 22:41:50 UTC, H. S. Teoh wrote:
It's time we came back to the essentials. Current monolithic
build systems ought to be split into two parts:
(1) Dependency detector / DAG generator. Do whatever you need
to do here: dub-style scanning of .d imports, scan
SumType is a generic sum type for modern D. It is meant as an
alternative to `std.variant.Algebraic`.
Features:
- Pattern matching, including support for structural matching
(★)
- Self-referential types, using `This`
- Works with pure, @safe, @nogc, and immutable (★)
- Zero runtime
On Thursday, 22 November 2018 at 00:02:18 UTC, H. S. Teoh wrote:
Any way this could be expanded to arbitrary types like Variant?
Or is that not possible without reverting to TypeInfo
dependency?
T
Not possible, unfortunately--for that and other reasons.
On Monday, 14 January 2019 at 03:58:37 UTC, Mike Franklin wrote:
What I wonder is, with design by introspection and the right
mix of other language features (e.g. `alias`, `alias this`,
mixins, etc...), what traditional language features can be
removed from the compiler and delegated to
On Tuesday, 22 January 2019 at 10:26:33 UTC, Mathias Lang wrote:
## Minivariant
https://github.com/Geod24/minivariant
Minivariant is a "works for me" replacement of `std.variant :
Algebraic`.
[...]
I looked into fixing it, but given Variant's design (which
relies heavily on `TypeInfo`) it
SumType is a generic sum type for modern D. It is meant as an
alternative to
`std.variant.Algebraic`.
Features:
- Pattern matching, including support for structural matching
(★)
- Self-referential types, using `This`
- Works with pure, @safe, @nogc, and immutable (★)
- Zero runtime
On Monday, 25 February 2019 at 20:41:58 UTC, Paolo Invernizzi
wrote:
Honestly, I've not understood the rationale or the covered use
case in letting the copy ctor mutate the ref source
parameters...
Sincerely, without polemical intent.
- P
Because D's const is transitive, you can't
On Tuesday, 26 February 2019 at 12:52:11 UTC, JN wrote:
On Monday, 25 February 2019 at 20:31:43 UTC, Paul Backus wrote:
SumType is a generic sum type for modern D. It is meant as an
alternative to
`std.variant.Algebraic`.
Is it a better alternative? Seems like it from the description.
If
On Sunday, 3 March 2019 at 14:32:55 UTC, Jacob Shtokolov wrote:
On Monday, 25 February 2019 at 20:31:43 UTC, Paul Backus wrote:
- Pattern matching, including support for structural
matching (★)
What is the main difference between 'match()' in this library
and 'visit()' in std.variant?
On Friday, 22 February 2019 at 17:09:41 UTC, Sönke Ludwig wrote:
- Behaves like a POD if only POD fields exist, is non-copyable
if any
contained type is non-copyable etc.
In fact, if a contained type is non-copyable, it fails to compile
altogether. (Example code below.)
Granted, so do
On Friday, 1 February 2019 at 23:24:44 UTC, Olivier FAURE wrote:
At no point is the compiler aware that the user intends for x
to be interpreted as a getter.
In theory, at least, that's what @property is for.
On Monday, 4 February 2019 at 18:35:37 UTC, bitwise wrote:
On Monday, 4 February 2019 at 18:32:56 UTC, Dominikus Dittes
Scherkl wrote:
I don't understand this.
What does "(return)?" mean? Is this valid D syntax? What do I
miss?
I meant for that to be interpreted like a Regular expression,
SumType is a generic sum type for modern D. It is designed to be
an improved
alternative to `std.variant.Algebraic`.
Features:
- Pattern matching, including support for introspection-based
matching (★)
- Self-referential types, using `This`
- Works with `pure`, `@safe`, `@nogc`,
On Sunday, 6 October 2019 at 21:49:59 UTC, Joseph Rushton
Wakeling wrote:
I'm not fluent in assembly so, leaving the error path aside, I
wasn't sure how to interpret the "main path" assembly from the
D and Rust code, and whether they were practically equivalent
(clearly the assembly posted
On Monday, 7 October 2019 at 01:09:34 UTC, Andrei Alexandrescu
wrote:
Well also in the case of SumType there's not even much
battle-testing. It's more of an implementation than a design.
Take the existing variant, keep the interface, remove the
cruft, put in the new nice code. Make it pass the
On Monday, 7 October 2019 at 08:07:01 UTC, Joseph Rushton
Wakeling wrote:
Where's the breaking change? Are there selections of handlers
that work for visit and don't work with match?
Yes.
https://run.dlang.io/is/UpaY2E
I was curious how C++17's std::variant compared to the options we
have in D, like Algebraic and SumType, so I did a simple
comparison of the generated assembly for each of them. You can
read about it at the link below. And as you can probably guess
from the title, D comes out ahead, in the
On Saturday, 5 October 2019 at 13:58:52 UTC, Seb wrote:
On Saturday, 5 October 2019 at 06:40:35 UTC, Arun
Chandrasekaran wrote:
Good one. Any plans to push SumType as a replacement of
Phobo's Algebraic?
Phobos is essentially dead/frozen (feature-wise). Though if
someone ever manages to get
On Saturday, 5 October 2019 at 04:07:45 UTC, Meta wrote:
I'm not sure if you're aware, but funnily enough, I also wrote
an article[1] on std::variant vs. the D alternative that
references Matt Kline's article on std::visit. It seems we're
really making getting our money's worth from his
On Tuesday, 28 January 2020 at 14:01:35 UTC, Mike Parker wrote:
Robert Schadek was inspired by a post he saw on Hacker News a
while back showing an implementation of wc in Haskell totaling
80 lines. He decided he could do better in D. So he did. This
post on the D blog shows what he came up
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
[...]
First, thank you for taking the time to summarize your position.
I understand
your objection to the proposed amendment much better
On Friday, 22 May 2020 at 05:37:55 UTC, Walter Bright wrote:
On 5/21/2020 8:36 PM, Paul Backus wrote:
Something ought to be done to prevent this. It doesn't have to
be the exact
proposal from the discussion thread, but doing nothing and
allowing widespread
silent breakage cannot possibly be
On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote:
On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
This is the nightmare scenario that people are worried about:
safety violations
being introduced *silently* into existing, correct D code.
Honest question: What is the use case
On Friday, 22 May 2020 at 14:43:27 UTC, bachmeier wrote:
If you're compiling a program that calls into C, you know
that's what you're doing, so you know you've given up any
guarantees of safety.
The entire problem is that with DIP 1028, I *don't* know what I'm
doing, because the compiler
On Saturday, 23 May 2020 at 15:33:05 UTC, H. S. Teoh wrote:
On Sat, May 23, 2020 at 10:55:40AM +
And this is precisely why I proposed that what we need is a way
for the compiler to mechanically check all code *except*
certain specified blackboxes that are skipped over. Then you
can have
On Thursday, 21 May 2020 at 17:03:49 UTC, bachmeier wrote:
The problem as I see it is someone making a decision on his own
DIP. That just doesn't make any sense to me, and I've stated
that numerous times. Walter has a tendency to throw gas on the
fire by ignoring much of the feedback and not
On Saturday, 12 September 2020 at 13:40:34 UTC, Per Nordlöw wrote:
On Saturday, 12 September 2020 at 13:03:29 UTC, Paul Backus
wrote:
How many improvements does this warning have to block before
we decide its value for the language is net-negative?
There's also the option of improving the
On Saturday, 12 September 2020 at 11:43:03 UTC, MoonlightSentinel
wrote:
Currently looking into enabling it by default but it showed an
interesting side effect. The frontend can now conclude that a
== b is always true if a and b are instances of an empty struct
(without custom opEquals).
On Thursday, 3 September 2020 at 09:24:01 UTC, Jacob Carlborg
wrote:
On Thursday, 3 September 2020 at 08:40:32 UTC, aberba wrote:
The slack I have no ideas how people get in. I know there's a
number of members in there too.
Unfortunately you need to be invited. Anyone can do it, if
you're
On Monday, 19 October 2020 at 13:59:42 UTC, Adam D. Ruppe wrote:
On Monday, 19 October 2020 at 13:43:14 UTC, Bastiaan Veelo
wrote:
I'm not suggesting that this fills the need of newbies, but
there is this: https://dlang.org/install.html.
Nobody should ever follow those terrible instructions,
On Wednesday, 26 August 2020 at 15:34:26 UTC, Dennis wrote:
On Wednesday, 26 August 2020 at 14:29:46 UTC, Dukc wrote:
I think there is a workaround to the variable access being
always safe. Something like this in a dedicated module:
```
struct SystemVar(T, bool safeVal)
{ private T _var;
On Thursday, 27 August 2020 at 14:10:36 UTC, Dennis wrote:
On Thursday, 27 August 2020 at 13:32:44 UTC, Paul Backus wrote:
Of course, you could also argue that these are things that
shouldn't be allowed in @safe code to begin with--regardless
of whether pointers are involved.
I did not
On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote:
https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html
Oops, wrong link. Here's the correct one:
https://pbackus.github.io/blog/what-does-memory-safety-really-mean-in-d.html
https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html
What exactly do we mean when we talk about "memory safety" in D?
Is it the same thing as "undefined behavior"? Is it ever correct
to mark and `extern(C)` function as `@trusted`? This post is my
attempt to understand, and
SumType is a generic sum type for modern D. It is designed to be
an improved
alternative to `std.variant.Algebraic`.
Features:
- Pattern matching, including:
- Match-by-introspection ("if it compiles, it matches") (★)
- Multiple dispatch (★)
- Support for self-referential types
On Wednesday, 27 May 2020 at 05:54:32 UTC, Walter Bright wrote:
On 5/26/2020 1:32 PM, Paul Backus wrote:
The reason extern function declarations are particularly
problematic is that changing them from @system-by-default to
@safe-by-default can cause *silent* breakage in existing,
correct
On Thursday, 28 May 2020 at 02:47:01 UTC, Jonathan M Davis wrote:
Walter has acknowledged the problem and seems to think that
because it's the programmer's responsibility to deal with
extern(C) functions correctly (since it's not possible for the
compiler to do it), it's up to the programmer
On Monday, 25 May 2020 at 13:22:36 UTC, Petar Kirov [ZombineDev]
wrote:
On Monday, 25 May 2020 at 13:14:51 UTC, Petar Kirov
[ZombineDev] wrote:
It may be true (of course modulo meta-programming) that it
doesn't make a difference for the calling code, but I
personally want have the guarantees
On Monday, 25 May 2020 at 15:07:19 UTC, Petar Kirov [ZombineDev]
wrote:
I don't want to change the definition of @safe in D, but would
rather like if D supported @strongSafe, that interested people
like me could opt into.
I know that worded like this it may sound like too narrow
feature to add
On Monday, 25 May 2020 at 12:30:11 UTC, Zoadian wrote:
On Monday, 25 May 2020 at 10:41:43 UTC, rikki cattermole wrote:
It is meant to mean that at some point it has been
mechanically checked by the compiler.
Either during current compilation or a prior one.
Which means it has to be valid on
On Monday, 25 May 2020 at 17:09:50 UTC, Clarice wrote:
On Monday, 25 May 2020 at 16:47:50 UTC, Paul Backus wrote:
the compiler must warn D programmers that their declarations
need to be reviewed for compatibility with @safe-by-default.
Whether they were reviewed before that or not makes no
On Monday, 25 May 2020 at 19:35:04 UTC, Clarice wrote:
I really appreciate your contributions. (The latter of which
will be quite handy.) But isn't the whole point of Walter's
implementation of @safe-as-default is that FFIs are going to be
assumed @safe? So they should still compile; that is
On Monday, 25 May 2020 at 18:39:16 UTC, mw wrote:
Can we declare the new D compiler version 3.0 for
@safe-as-default? and keep version 2.x compiler for the old
@system-as-default?
@safe-by-default is currently hidden behind a -preview switch. I
think it's safe to assume there will be a
On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
On Sunday, 24 May 2020 at 16:44:01 UTC, Paul Backus wrote:
If we were designing a new language from scratch, I would
agree 100% with your reasoning.
The problem is that there are un-annotated declarations in
existing code that have
On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote:
I'd like to emphasize:
1. It is not possible for the compiler to check any
declarations where the implementation is not available. Not in
D, not in any language. Declaring a declaration safe does not
make it safe.
2. If
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
The subject says it all.
If you care about memory safety, I recommending adding `safe:`
as the first line in all your project modules, and annotate
individual functions otherwise as necessary. For modules with C
declarations, do as
On Saturday, 30 May 2020 at 16:17:49 UTC, Steven Schveighoffer
wrote:
+1 this would be perfect.
Not sure if this would work either, but both of these are
already reserved words:
default @safe:
-Steve
It would probably have to be something more like
`default(@safe)`, since `default
On Saturday, 30 May 2020 at 21:48:32 UTC, Johan wrote:
Great work.
Which compilers (and versions) are available?
-Johan
Looks like dmd [1], ldc [2], and gdc [3] are all there.
[1] https://pkgs.alpinelinux.org/package/edge/community/x86_64/dmd
[2]
On Tuesday, 26 May 2020 at 22:47:03 UTC, Gregory wrote:
If Walter believed greenwashing was actually a problem, then
the best solution to prevent it would be to not make @safe by
default. If it's not that serious of a problem that he will
push through @safe by default, then greenwashing isn't
On Tuesday, 26 May 2020 at 17:50:58 UTC, Gregory wrote:
Which will just lead people to pure @trusted: at the top of
their code to get it to compile again, with or without
extern(C) being @safe by default. Then someone that uses it as
dependency will mistaken think it is @safe. What's to stop
On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote:
DIP 1028, "Make @safe the Default", has been accepted without
comment.
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md
I've made a draft PR to try and address the potential safety
issue discussed in this thread.
On Friday, 22 May 2020 at 19:16:26 UTC, ag0aep6g wrote:
I for one liked it better when it had that aspiration. And I
was contributing towards that goal (latest PR was merged just
yesterday, coincidentally [1]).
[1] https://github.com/dlang/dlang.org/pull/2773
Thank you for that PR, by the
On Thursday, 2 July 2020 at 14:56:09 UTC, aberba wrote:
Why no one is using your D library
So I decided to write a little something special. Its my love
letter to D folks.
https://aberba.vercel.app/2020/why-no-one-is-using-your-d-library/
Excellent article. As the author of a
On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote:
With a few changes, yes (added missing semicolons, changed
IGeometry to Geometry in `measure`, passed the current module
so tardy can find the UFCS functions, added `@safe pure` to the
UFCS functions:
[...]
void main() {
On Wednesday, 24 June 2020 at 16:15:30 UTC, Andrei Alexandrescu
wrote:
On 6/23/20 10:31 AM, Meta wrote:
By the way I found this helpful:
https://chrome.google.com/webstore/detail/smile-always/jgpmhnmjbhgkhpbgelalfpplebgfjmbf?hl=en
And for firefox users:
On Saturday, 27 June 2020 at 15:06:12 UTC, Avrina wrote:
Do you understand what prioritizing is? Fake internet points
are being prioritized over ease of access to the community.
Another way to frame it is that "respecting the rules of another
community (HN) is being prioritized over a minor
On Sunday, 14 June 2020 at 16:26:17 UTC, Avrina wrote:
The situation also applies to the only tuple implementation in
D. If you are proposing a new type with emphasis on reducing
the footprint of the tuple then I don't see a problem with
that. Changing the existing tuple implementation would
Are you tired of D's sane, straightforward scoping rules? Itching
for a taste of that old-fashioned C++ madness? Well, itch no
more: addle is here to help.
addle is a tiny library that implements C++-style
argument-dependent lookup (ADL) for D, on an opt-in basis. It
lets you extend existing
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
https://code.dlang.org/packages/tardy
https://github.com/atilaneves/tardy
Cool stuff!
What's the reasoning behind implementing your own vtables instead
of using D's built-in object system? Don't want to be stuck
inheriting from
On Thursday, 23 July 2020 at 14:43:23 UTC, Mike Parker wrote:
I've just published the formal announcement of DConf Online
2020 to the blog and shared it on reddit. If you have time,
please check the comments in the reddit thread for any
questions you can answer and myths you can refute about
On Saturday, 25 July 2020 at 18:24:22 UTC, Jesse Phillips wrote:
On Saturday, 25 July 2020 at 14:47:01 UTC, aberba wrote:
On Saturday, 25 July 2020 at 13:28:34 UTC, Adam D. Ruppe wrote:
On Saturday, 25 July 2020 at 11:12:16 UTC, aberba wrote:
Oop! Chaining the writeln too could have increased
On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
Of course, the typical response would be, "well why not use
alias s = static array". I would ask what about an @nogc
unittest where the author is trying to limit calls to functions
that aren't really central to what is being tested.
On Monday, 11 January 2021 at 22:28:04 UTC, jmh530 wrote:
On Monday, 11 January 2021 at 21:33:36 UTC, Paul Backus wrote:
On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
Of course, the typical response would be, "well why not use
alias s = static array". I would ask what about an
On Tuesday, 24 November 2020 at 23:02:15 UTC, Dibyendu Majumdar
wrote:
Thanks - I was suggesting adding a description to the
documentation, unless it is already there. Also an ABI
specification would be helpful - what happens when a value is
passed to a C program.
Thanks for the
On Tuesday, 24 November 2020 at 21:52:47 UTC, Dibyendu Majumdar
wrote:
On Sunday, 15 November 2020 at 20:05:16 UTC, Paul Backus wrote:
SumType is a generic discriminated union type for modern D. It
is designed to
be an improved alternative to `std.variant.Algebraic`.
Nice. Is it possible to
On Wednesday, 25 November 2020 at 00:56:39 UTC, sarn wrote:
On Wednesday, 25 November 2020 at 00:20:54 UTC, Paul Backus
wrote:
The exact memory layout and ABI of SumType is deliberately
left unspecified. It's an implementation detail that client
code isn't supposed to rely on. If you want to
On Tuesday, 22 December 2020 at 03:56:13 UTC, 9il wrote:
On Sunday, 20 December 2020 at 11:00:05 UTC, Tobias Pankrath
wrote:
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:
Truly algebraic Variant and Nullable with an
order-independent list of types.
Thanks for sharing it!
Could you
1 - 100 of 169 matches
Mail list logo
