On Thursday, 22 February 2018 at 08:52:21 UTC, Timothee Cour
wrote:
you should also mention an important point:
current syntax disallows importing a simple module foo (with no
package), eg:
import std.stdio:write,foo; // there's no way to specify a
module `foo` import std.stdio:write & foo;
On Thursday, 22 February 2018 at 13:51:18 UTC, Seb wrote:
On Thursday, 22 February 2018 at 13:35:00 UTC, aliak wrote:
barring a revert,
Who says we can't revert it?
https://github.com/dlang/dmd/pull/7939
On the contrary, imho if it's so controversial it should be
reverted now, s.t. it
On Monday, 26 February 2018 at 16:02:58 UTC, Dukc wrote:
I kinda start to see the idea... Granted, nullable is in a way
a range that can hold exactly one or exactly zero elements. Not
a bad idea at all.
Aye, ranges do not need nullability indeed. Optional doesn't need
to adhere to the
On Monday, 26 February 2018 at 18:17:51 UTC, Adam D. Ruppe wrote:
Oh, fixed now. since there's no ddoc at all in that file, it
should have been skipped, I just had a testing "return true;"
in the method I forgot to remove.
Nice :D Looks good.
ketmar sent me a patch to parse a .adrdox_ignore
Hi, just a release of a meta programming library
(https://bolts.dub.pm) that has utilities that I use in personal
projects, and that I find in phobos, and or in the forums. A
notable difference is that functions here try to operate on any
compile time entities if they can be resolved.
I.e.:
On Thursday, 2 August 2018 at 08:45:33 UTC, John Colvin wrote:
On Thursday, 2 August 2018 at 08:40:55 UTC, John Colvin wrote:
This looks cool. Lots of things that lots of people have
reimplemented lots of times over the years, but all in one
place and documented.
2 points:
1) Are you aware
On Thursday, 2 August 2018 at 12:06:16 UTC, Patrick Schluter
wrote:
On Thursday, 2 August 2018 at 10:31:02 UTC, aliak wrote:
On Thursday, 2 August 2018 at 08:45:33 UTC, John Colvin wrote:
[...]
Thanks! And yes, totally aware of that. I have tried to link
to relevant forum posts and will try
Hi
See: https://optional.dub.pm
I've totally revamped the Optional type and am now quite happy
with. It has a range interface and safe dispatching and can be
used to 1) avoid null dereferencing, 2) have non-null guarantees,
and 3) show clear intent where there may or may not be a value.
On Thursday, 16 August 2018 at 15:38:50 UTC, Paul Backus wrote:
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
On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
It's also @nogc and @safe
No it's not. Not dispatching at least. Dunno why though. Seems
safey is because taking an address. Nogc will have to look in to.
On Friday, 17 August 2018 at 06:59:48 UTC, Petar Kirov
[ZombineDev] wrote:
On Thursday, 16 August 2018 at 18:10:38 UTC, jmh530 wrote:
On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
Hi
See: https://optional.dub.pm
I've totally revamped the Optional type and am now quite
happy
On Wednesday, 22 August 2018 at 22:49:52 UTC, Paul Backus wrote:
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?
On Monday, 20 August 2018 at 09:16:18 UTC, ikod wrote:
On Thursday, 16 August 2018 at 16:20:09 UTC, aliak wrote:
On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
It's also @nogc and @safe
No it's not. Not dispatching at least. Dunno why though. Seems
safey is because taking an
On Monday, 27 August 2018 at 05:22:30 UTC, FeepingCreature wrote:
- Consider a short form for "dispatch". Purely for convenience:
e.g.: john.d.residence.d.numberOfRooms;
Why not .get, like Nullable?
As long as you never alias it to this... ;)
Mmm... get is indicative of getting the value.
On Thursday, 19 July 2018 at 13:10:01 UTC, Martin Tschierschke
wrote:
On Thursday, 19 July 2018 at 09:39:04 UTC, Seb wrote:
[...]
Very ++ :-)
There should be a big section for well done dub.sdl / dub.json
examples.
What about defining "comment" as an special keyword for the
.json parser
On Wednesday, 28 February 2018 at 10:55:38 UTC, Andrei
Alexandrescu wrote:
On 2/28/18 12:54 PM, Andrei Alexandrescu wrote:
On 2/25/18 8:03 PM, aliak wrote:
Did you take a look at
https://dlang.org/library/std/range/only.html? -- Andrei
Ah, sorry I missed that you mentioned it. -- Andrei
On Wednesday, 14 March 2018 at 11:44:10 UTC, Simen Kjærås wrote:
https://issues.dlang.org/show_bug.cgi?id=5710 might be worth
it, even if it means moving from friends and a comfy job in
Norway...
--
Simen
!!! Haha Norway? So up for a Norway D meetup? Oslo? Turns out I
even work with
On Monday, 26 February 2018 at 14:59:07 UTC, Adam D. Ruppe wrote:
Many of you will already know this from the other thread or
from my twitter, but I just added a on-demand downloader to my
dpldocs.info domain to fetch and build docs for any* dub
package.
Simply go to
On Tuesday, 27 February 2018 at 11:58:34 UTC, Dukc wrote:
On Monday, 26 February 2018 at 20:04:14 UTC, aliak wrote:
Guess I could do a pointer and call new when i need to store a
value instead. Or maybe it's better to do it like above and
store as value type with default value and a boolean at
Alo,
Just finished up a first take on an optional type for D. It's
essentially a mix of Nullable and std.range.only, but with a lot
more bells and whistles. I would love to hear any feedback on
code, or features, or bad design or potential for better designs
from anyone who's interested :)
On Monday, 12 November 2018 at 22:07:39 UTC, Walter Bright wrote:
On 11/12/2018 12:34 PM, Neia Neutuladh wrote:
Tell me more about this "consistency".
int f(short s) { return 1; }
int f(int i) { return 2; }
enum : int { a = 0 }
enum A : int { a = 0 }
pragma (msg, f(a)); // calls f(int)
On Tuesday, 13 November 2018 at 09:17:51 UTC, Walter Bright wrote:
On 11/13/2018 12:23 AM, aliak wrote:
Doesn't the above miss a step, and wouldn't it be:
1) A.a =>
2) A.a =>
So basically for the f(short) path you have 3 steps instead of
2 for the f(int) path.
So does it matter how
On Saturday, 29 September 2018 at 19:27:29 UTC, Paul Backus wrote:
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);
On Friday, 28 September 2018 at 17:33:04 UTC, Paul Backus wrote:
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
On Saturday, 29 September 2018 at 01:40:34 UTC, Robby Marki wrote:
On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:
Hi,
I've been working for fun on a library [0] that is inspired by
a library from the javascript world called lodash [1]. I
basically liked the flexibility and
Hi,
I've been working for fun on a library [0] that is inspired by a
library from the javascript world called lodash [1]. I basically
liked the flexibility and thought I'd try and implement a few
things as it was about the time I started learning D. It
basically tried to do the same with
On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:
Hi,
[...]
PS Docs: https://aliak00.github.io/ddash/ddash/algorithm.html
On Monday, 1 October 2018 at 00:51:24 UTC, Paul Backus wrote:
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?
On Saturday, 29 September 2018 at 12:44:38 UTC, aliak wrote:
On Saturday, 29 September 2018 at 01:40:34 UTC, Robby Marki
wrote:
On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:
[...]
In this example
https://aliak00.github.io/ddash/ddash/functional/try_.html
where does the match
On Monday, 3 September 2018 at 06:49:41 UTC, Paul Backus wrote:
To me, the only acceptable choices are for `Expected!void` to
have the same lazy semantics as `Expected!T`, or for
`Expected!void` to be removed altogether. Having one
specialization be lazy and one be eager would be a nightmare
On Monday, 3 September 2018 at 06:00:06 UTC, Thomas Mader wrote:
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev
wrote:
There are generally two classic approaches to error handling:
std::expected is not the only thing on this topic going on in
C++.
There is also the proposal
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu
wrote:
https://youtube.com/watch?v=tcyb1lpEHm0
If nothing else please watch the opening story, it's true and
quite funny :o).
Now as to the talk, as you could imagine, it touches on another
language as well...
Andrei
On Tuesday, 15 January 2019 at 06:57:28 UTC, Paul Backus wrote:
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
On Wednesday, 5 December 2018 at 23:18:12 UTC, rikki cattermole
wrote:
On 06/12/2018 10:18 AM, aliak wrote:
"Weka is a name of a Machine learning product from New Zealand.
Weka is the company that produced Lord of the Rings here in NZ.
*Weta.
Bless them :D
Weka is a set of ML tools from
On Wednesday, 5 December 2018 at 19:59:46 UTC, Joakim wrote:
On Wednesday, 5 December 2018 at 09:04:49 UTC, Walter Bright
wrote:
#4 on HackerNews front page!
https://news.ycombinator.com/
33 points at the moment!
Now one of the top-voted links on the front page of HN.
I'd just like to
On Monday, 17 September 2018 at 23:32:39 UTC, Jonathan M Davis
wrote:
On Monday, September 17, 2018 5:07:22 PM MDT Manu via
Digitalmars-d-announce wrote:
[...]
Except that @implicit could be introduced for other
constructors without having it on copy constructors, and the
fact that copy
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis
wrote:
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via
Digitalmars-d- announce wrote:
This will break compilation of current code that has an
explicit copy constructor, and the fix is simply to add the
attribute
On Sunday, 3 March 2019 at 17:44:21 UTC, Andre Pany wrote:
On Sunday, 3 March 2019 at 14:01:03 UTC, aliak wrote:
On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote:
Glad to announce D 2.085.0, ♥ to the 49 contributors.
This release comes with context-aware assertion messages,
On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote:
Glad to announce D 2.085.0, ♥ to the 49 contributors.
This release comes with context-aware assertion messages, lower
GC memory usage, a precise GC, support to link custom GCs, lots
of Objective-C improvements¹, and
On Monday, 18 March 2019 at 10:05:40 UTC, Jacob Carlborg wrote:
On 2019-03-17 21:09, Per Nordlöw wrote:
I thought that already is the case...
No, the official binaries are built with DMD as the host
compiler.
How come they're not built with LDC (for example) and then
distributed? I'd
On Thursday, 31 January 2019 at 21:50:32 UTC, Steven
Schveighoffer wrote:
On 1/31/19 4:46 PM, Olivier FAURE wrote:
On Thursday, 31 January 2019 at 18:31:22 UTC, Steven
Schveighoffer wrote:
BTW, the DIP discusses how to annotate these rare situations:
int doubleMyValue(ref int x) { ... }
On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote:
On 01.02.19 10:10, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a
getter? For it not to be a compile error pt.x should also have
a setter, in which case the code needs to be lowered to
something
On Friday, 1 February 2019 at 14:41:52 UTC, 12345swordy wrote:
On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote:
On 01.02.19 10:10, aliak wrote:
[...]
http://wilzbach.github.io/d-dip/DIP24
I'm not sure your rewrite is good though, because it does not
preserve aliasing during
Hey,
I've recently released optional 0.15.0 [0] that includes support
for vibe-d serialization/deserialization. So you can use it
instead of Nullable for types that may or may not be there (I got
bit by Nullable again so felt this had to be added [1])
Also of note is that it can be used in
On Sunday, 16 June 2019 at 22:47:57 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.087.0 release, ♥ to
the 66 contributors.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.087.0.html
As usual please report any bugs at
https://issues.dlang.org
On Thursday, 20 June 2019 at 17:36:45 UTC, kinke wrote:
Glad to announce LDC 1.16:
* Based on D 2.086.1.
* Non-Windows x86: Faster `real` versions of
std.math.{tan,expi}.
* Windows: Fix linking DLLs with MinGW-based libs.
* WebAssembly: No need for an explicit `-L--export-dynamic`
anymore.
On Thursday, 9 May 2019 at 21:14:02 UTC, kinke wrote:
Glad to announce the first beta for LDC 1.16; mainly just an
upgrade to D 2.086.0.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.16.0-beta1
Please help test, and thanks to all contributors!
Yay!!
On Friday, 26 April 2019 at 06:29:04 UTC, Simen Kjærås wrote:
On Thursday, 25 April 2019 at 23:41:32 UTC, Suleyman wrote:
[...]
You have no idea how happy I am to hear this has been fixed! So
many of my designs have been hamstrung by 5710, and it's been
around since the dawn of time.
--
On Wednesday, 26 June 2019 at 15:20:45 UTC, ag0aep6g wrote:
On 26.06.19 16:01, SHOO wrote:
[...]
You've got bad `@trusted`s.
Quoting from there:
[...]
No.
[...]
[...]
[...]
Noo.
[...]
[...]
[...]
[...]
[...]
[...]
[...]
Nooo.
[...]
[...]
[...]
[...]
[...]
[...]
I've been using a set of meta tools for a while now, so decided
to release it as 1.0.0 with a few enhancements chucked on.
Two of the highlights are the non-eponymous "member" and "iz"
templates, which are shown below with some code. The library also
includes the "from" template because I
On Thursday, 25 April 2019 at 23:41:32 UTC, Suleyman wrote:
Hello everyone,
I am happy to announce that in the next DMD release you will be
able to more freely enjoy your metaprograming experience now
that a long-standing limitation has been lifted.
You can now instantiate local and member
On Monday, 29 July 2019 at 22:17:20 UTC, aliak wrote:
Hi
Link: https://code.dlang.org/packages/optional
Hi,
After some feedback from the community [0], I'm happy to finally
get the optional package to a 1.0.0 version. There is one
breaking change with how pointer semantics behave, in that the
previous version treated some!(int*)(null) as a non-empty
optional, and some!Class(null) as an empty
On Saturday, 10 August 2019 at 15:51:28 UTC, kinke wrote:
Glad to announce the first beta for LDC 1.17:
Nice!
* Based on D 2.087.1+ (stable from some days ago).
* The DMD fix wrt. 'local templates can now receive local
Are there plans to port this or is it just too unworkable as is?
On Tuesday, 30 July 2019 at 04:18:28 UTC, Les De Ridder wrote:
On Monday, 29 July 2019 at 22:17:20 UTC, aliak wrote:
[...]
* dispatch() has been renamed to oc(); "optional chain"
Why not 'chain()' or 'optionalChain()'?
Only because chain is in range and optionalChain is too long 路♂️.
On Tuesday, 30 July 2019 at 12:58:08 UTC, Jesse Phillips wrote:
On Monday, 29 July 2019 at 22:17:20 UTC, aliak wrote:
* NotNull has been removed
Why was it removed. It seems like this would be nice to have
for class and pointers.
I personally didn't find use for it, too much friction to
On Wednesday, 17 July 2019 at 16:29:34 UTC, victoroak wrote:
On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so
decided to release it as 1.0.0 with a few enhancements chucked
on.
[...]
Looks nice. Though, I see it has some problems
On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote:
On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so
decided to release it as 1.0.0 with a few enhancements chucked
on.
[...]
Nice! I'm working on something similar but with
On Tuesday, 23 July 2019 at 07:57:06 UTC, zoujiaqing wrote:
A Powerfull Redis client library for D Programming Language.
Porting from java Jedis, support redis 3.x / 4.x all features
and 5.x
some features.
[...]
Awesome! Huntlabs seem to really be putting in a lot of work on
backend
On Thursday, 26 September 2019 at 15:58:46 UTC, Andre Pany wrote:
Hi,
Based on the voting results
(https://www.codingame.com/forum/t/poll-what-programming-language-would-you-like-codingame-to-support-next) Codingame is currently adding 2 new programming languages, Type Script and D!
Thanks
On Sunday, 3 November 2019 at 00:51:38 UTC, Murilo wrote:
Hi guys. I'm eager to attend the next DConf, which is why I'm
already planning everything about how I will travel from Brazil
to the UK(or maybe Germany). When will you announce the place
and date of the next DConf?
Hey! That’s
On Wednesday, 13 November 2019 at 23:17:21 UTC, WebFreak001 wrote:
hi everyone,
after a long time there is finally a new update for my Visual
Studio Code extension "code-d"
[...]
Wow! Well done on the effort!!
On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote:
Hi all,
Recently there have been inquiries about support for D on
Alpine Linux, a distribution mostly used in combination with
Docker to create lightweight container images for microservices.
[...]
This is great! Much thanks
On Wednesday, 16 October 2019 at 12:11:23 UTC, bachmeier wrote:
On Wednesday, 16 October 2019 at 09:46:49 UTC, aliak wrote:
On Tuesday, 15 October 2019 at 20:33:32 UTC, Walter Bright
wrote:
On 10/15/2019 6:11 AM, Mike Parker wrote:
Reddit:
On Wednesday, 16 October 2019 at 17:55:24 UTC, Meta wrote:
On Wednesday, 16 October 2019 at 09:46:49 UTC, aliak wrote:
It's better to link straight to an item on hackernews as links
on the front page disappear very fast.
https://news.ycombinator.com/item?id=21257943
Cheers,
- Ali
HN has
On Tuesday, 15 October 2019 at 20:33:32 UTC, Walter Bright wrote:
On 10/15/2019 6:11 AM, Mike Parker wrote:
Reddit:
https://www.reddit.com/r/d_language/comments/di7gwl/%C3%A1tilas_vision_of_ds_future/
It's also on the front page of hacker news:
https://news.ycombinator.com/news
It's better
On Monday, 24 February 2020 at 21:23:43 UTC, Adam D. Ruppe wrote:
On Monday, 24 February 2020 at 20:55:16 UTC, Walter Bright
wrote:
and proposed a lowering to:
> i"your hex data is ${%02x}someByte"
>
> (_d_interpolated_string!("your hex data is ",
> _d_interpolated_format_spec("%02x"))(),
On Wednesday, 26 February 2020 at 09:45:55 UTC, Walter Bright
wrote:
On 2/25/2020 1:36 AM, aliak wrote:
This may have already been answered in the other threads, but
I was just wondering if anyone managed to propose a way to
avoid this scenario with DIP1027?
void f(string s, int i = 0);
On Tuesday, 25 February 2020 at 16:04:59 UTC, Arine wrote:
``How to distinguish a different type? Use a different type.
No, is there another simpler way to do that instead?``
Is this really the line of thinking going on here? It seems
Walter has these arbitrary rules he's following which led
On Friday, 28 February 2020 at 19:16:08 UTC, Steven Schveighoffer
wrote:
On 2/28/20 5:17 AM, Jacob Carlborg wrote:
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright
wrote:
I don't know Swift, but this looks like the "generate strings
and concatenate them" approach.
No, it
On Saturday, 29 February 2020 at 14:41:16 UTC, Steven
Schveighoffer wrote:
On 2/28/20 7:57 PM, aliak wrote:
I actually didn't realize it was a video, thought it was just
an article! - But anyway, it was just to point out that swift
lowers to specialized types when it comes to interpolation
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp
On Tuesday, 25 February 2020 at 07:07:50 UTC, Walter Bright wrote:
All DIP1027 did was turn an istring into a tuple. That's it.
The user can then do whatever they want with the tuple,
including overloading a custom function based on the tuple
arguments. DIP1027 did not actually do ANY
On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote:
On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
[...]
Yes, that is the key impetus of our amendment, which I also
wrote up on a gist weeks ago and it is now on github too!
On Thursday, 27 February 2020 at 18:19:03 UTC, Adam D. Ruppe
wrote:
On Thursday, 27 February 2020 at 17:41:12 UTC, Petar Kirov
[ZombineDev] wrote:
[...]
Right, that actually is what my old proposal was (and I fought
for it on the first few pages of the last thread), and this is
very close
On Friday, 14 February 2020 at 21:33:01 UTC, aliak wrote:
Hi,
[...]
Cheers,
- ali
Ok, you can now model an actual input range with most of it's
caveats:
interface InputRange(T) {
@property bool empty();
@property T front();
@ignoreAttributes void popFront();
}
struct MyRange {
Hi,
I've released an experimental implementation of the concept of
traits/signatures/protocols-ish. The basics seems to work
decently well, with very decent error messages e.g.:
source/bolts/experimental/signature.d(111,17): Error: static
assert: "Type Y is missing the following members of
On Tuesday, 7 April 2020 at 19:12:49 UTC, Laurent Tréguier wrote:
I started working on this project to make it more comfortable
to write D back in 2017, published a VSCode extension a couple
months later, and continued working on it throughout 2018. In
2019 however, I slowed down, and
On Tuesday, 7 April 2020 at 22:20:40 UTC, Laurent Tréguier wrote:
On Tuesday, 7 April 2020 at 20:03:21 UTC, Aliak wrote:
Is what you’re working on shareable information (just out of
curiosity)?
It's shareable (it's on Github just like DLS); it's a mobile
app, the Android version is in
First, thank you for the explanation! I have a few observations
though, mainly that the exception analogy feels like more an
argument against the DIP than for it. And I also have an
alternative proposal that might be considered?
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
does not work). But I admit that it is still a bit weird to
have 2 different defaults.
Is that any more or less weirder than having functions inferred
with different attributes based on context?
On Sunday, 24 May 2020 at 11:30:53 UTC, Johannes Loher wrote:
On Sunday, 24 May 2020 at 11:25:06 UTC, aliak wrote:
On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
does not work). But I admit that it is still a bit weird to
have 2 different defaults.
Is that any more or less
On Wednesday, 27 May 2020 at 02:42:24 UTC, Walter Bright wrote:
On 5/24/2020 6:04 PM, Timon Gehr wrote:
Implicit greenwashing by the compiler is a nuisance that makes
it harder to do the job correctly and easier to do the wrong
thing.
You and I are just going to disagree about that.
On Saturday, 25 July 2020 at 16:22:52 UTC, H. S. Teoh wrote:
On Sat, Jul 25, 2020 at 01:28:34PM +, Adam D. Ruppe via
Digitalmars-d-announce wrote:
On Saturday, 25 July 2020 at 11:12:16 UTC, aberba wrote:
> Oop! Chaining the writeln too could have increased the wow
> factor. I didn't see
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`.
[...]
Alright!! A 1.0.0 release! Awesome work here!
85 matches
Mail list logo