On 17.07.19 22:59, Walter Bright wrote:
Any competing system would need to not be 'opt-in' on a type by type
basis. I.e. the central feature of an @live function is the user will
not be able to write memory unsafe code within that function.
Those two things are not the least bit at odds with
On 21.07.19 02:17, Walter Bright wrote:
On 7/20/2019 3:39 PM, Sebastiaan Koppe wrote:
Do you mean to keep track of ownership/borrowedness manually?
No, that's what the copyctor/opAssign/dtor semantics so.
This is not true.
On 23.07.19 10:20, Sebastiaan Koppe wrote:
On Tuesday, 23 July 2019 at 04:02:50 UTC, Timon Gehr wrote:
On 21.07.19 02:17, Walter Bright wrote:
On 7/20/2019 3:39 PM, Sebastiaan Koppe wrote:
Do you mean to keep track of ownership/borrowedness manually?
No, that's what the copyctor/opAssign/dto
On 22.05.20 03:22, Walter Bright wrote:
This is Obviously A Good Idea. Why would I oppose it?
1. I've been hittin' the crack pipe again.
2. I was secretly convinced, but wanted to save face.
3. I make decisions based on consultation with my astrologer.
4. I am evil.
5. You are backwards-ratio
On 22.05.20 15:58, bachmeier wrote:
...
Honest question: What is the use case for an
absolutely-positively-has-to-be-safe program that calls C code? Why
would anyone ever do that? C is not and will never be a safe language.
"Someone looked at that blob of horrendous C code and thinks it's saf
On 22.05.20 16:49, bachmeier wrote:
On Friday, 22 May 2020 at 14:38:09 UTC, Timon Gehr wrote:
On 22.05.20 15:58, bachmeier wrote:
...
Honest question: What is the use case for an
absolutely-positively-has-to-be-safe program that calls C code? Why
would anyone ever do that? C is not and will
On 22.05.20 18:43, Adam D. Ruppe wrote:
On Friday, 22 May 2020 at 16:39:42 UTC, jmh530 wrote:
Fortunately, the above point can be more easily fixed by making `free`
@system
With the o/b system `free` might actually work out OK
free(new int);
On 24.05.20 05:28, Walter Bright wrote:
I'd like to emphasize:
I understand all of those points and most of them are true, and obvious.
The issue is that they are not a justification for the decision. You
seem to think that greenwashing is not greenwashing when it is done by
the compiler wi
On 24.05.20 10:55, Walter Bright wrote:
I infer your position is the idea that putting @trusted on the
declarations isn't greenwashing, while @safe is.
...
It's only greenwashing if it's misleading. Putting @safe is a lie,
putting @trusted is honest.
I can't see a practical difference betw
On 24.05.20 11:10, Walter Bright wrote:
On 5/23/2020 11:26 PM, Bruce Carneal wrote:
I don't believe that you or any other competent programmer greenwashes
safety critical code. Regardless, the safety conscious must review
their dependencies whatever default applies.
That's the theory. But we
On 25.05.20 11:25, Johannes T wrote:
@trusted can't be trusted
That's the point of @trusted. ._.
The code is trusted by the programmer, not the annotation by the compiler.
On 25.05.20 14:22, Johannes T wrote:
On Monday, 25 May 2020 at 11:52:27 UTC, Timon Gehr wrote:
On 25.05.20 11:25, Johannes T wrote:
@trusted can't be trusted
That's the point of @trusted. ._.
The code is trusted by the programmer, not the annotation by the
compiler.
Sorry, I phrased it po
On 26.05.20 13:09, Atila Neves wrote:
On Monday, 25 May 2020 at 17:01:24 UTC, Panke wrote:
On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
A few years ago I submitted several PRs to Phobos to mark all
unittests that could with @safe explicitly. I'd say that was a good
example of nob
On 27.05.20 11:34, Bastiaan Veelo wrote:
On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
On 5/26/2020 11:20 PM, Bruce Carneal wrote:
I'm not at all concerned with legacy non-compiling code of this nature.
Apparently you agree it is not an actual problem.
Really? I don't know
On 27.05.20 07:54, 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 code.
Can you post an exampl
On 27.05.20 12:51, Walter Bright wrote:
On 5/27/2020 3:01 AM, Timon Gehr wrote:
This is clearly not possible, exactly because the old @safe rules are
stronger.
Thank you. We can agree on something.
...
I am not sure if you noticed that I agree with most of your points, just
not about their
On 28.05.20 10:50, Daniel Kozak wrote:
He seems to think
that weakening @safe is worth doing, because it will ultimately mean that
more code will be treated as @safe and mechnically checked by the compiler,
And I believe he is right.
No, it's a false dichotomy. Weakening @safe to allow more c
On 29.05.20 06:53, Walter Bright wrote:
The subject says it all.
Thanks! For the record, this would have been my preference:
fix @safe, @safe by default >
fix @safe, @system by default >
don't fix @safe, @system by default >
don't fix @safe, @safe by default
While this retraction
On 13.06.20 21:11, Andrei Alexandrescu wrote:
https://github.com/ZigaSajovic/optimizing-the-memory-layout-of-std-tuple
Would be interesting to adapt it for std.tuple.
That's likely to run into the following arbitrary language limitation:
---
alias Seq(T...)=T;
struct T{
int a,b;
alia
On 14.06.20 20:25, Paul Backus wrote:
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 th
On 04.06.20 14:46, Andrei Alexandrescu wrote:
PLDI (Programming Language Design and Implementation) is a top academic
conference. This year PLDI will be held online and registration is free.
This is an amazing treat.
https://conf.researchr.org/home/pldi-2020
Workshops and tutorials (also free
On 15.06.20 08:58, Robert M. Münch wrote:
On 2020-06-14 20:22:41 +, Timon Gehr said:
https://pldi20.sigplan.org/details/pldi-2020-papers/46/-PSI-Exact-Inference-for-Higher-Order-Probabilistic-Programs
This one sounds pretty interesting. Will there be a recording and a
published paper be
On 15.06.20 09:46, M.M. wrote:
On Sunday, 14 June 2020 at 20:22:41 UTC, Timon Gehr wrote:
For PLDI 2020, I have contributed to the following research papers:
https://pldi20.sigplan.org/details/pldi-2020-papers/47/Silq-A-High-Level-Quantum-Language-with-Safe-Uncomputation-and-Intuitive-Semantic
On 15.06.20 16:03, Max Samukha wrote:
On Monday, 15 June 2020 at 13:57:01 UTC, Max Samukha wrote:
void main() {
Tuple!(byte, int, short) t;
writeln(t[0]);
}
test.d(57,23): Error: need `this` for `__value_field_2` of type `byte`
It should work. This works:
void main() {
Tuple!(b
On 16.06.20 17:35, Robert M. Münch wrote:
On 2020-06-15 13:01:02 +, Timon Gehr said:
The talk will be on YouTube.
Great.
Papers:
https://www.sri.inf.ethz.ch/publications/bichsel2020silq
https://www.sri.inf.ethz.ch/publications/gehr2020lpsi
Source code:
https://github.com/eth-sri/silq
h
On 23.12.20 16:37, Ola Fosheim Grøstad wrote:
On Wednesday, 23 December 2020 at 03:06:51 UTC, 9il wrote:
You, Andrey, and Atila don't care about language features that have
been requested for Mir or even more: rejecting DIP draft + DMD partial
implementation for no real reason.
Out of curiosi
On 06.01.21 03:27, Walter Bright wrote:
On 1/5/2021 5:30 AM, Guillaume Piolat wrote:
It would be nice if no excess precision was ever used. It can
sometimes gives a false sense of correctness. It has no upside except
accidental correctness that can break when compiled for a different
platform.
On 06.01.21 07:50, Walter Bright wrote:
> I want to execute the code that I wrote, not what you think I should
have
> instead written, because sometimes you will be wrong.
With programming languages, it does not matter what you think you wrote.
What matters is how the language semantics ar
On 18.01.21 10:21, Mike Parker wrote:
Thanks once more to Symmetry Investments, we have a new paid staffer in
the D Language Foundation family.
Though I call him my "assistant", I can already see he will be more than
that. He'll be taking some things off my shoulders, sure, but he also
has id
On 24.01.21 14:00, Max Haughton wrote:
On Sunday, 24 January 2021 at 12:36:16 UTC, Timon Gehr wrote:
On 18.01.21 10:21, Mike Parker wrote:
Thanks once more to Symmetry Investments, we have a new paid staffer
in the D Language Foundation family.
Though I call him my "assistant", I can already
On 25.01.21 11:05, Imperatorn wrote:
On Monday, 25 January 2021 at 06:59:00 UTC, ag0aep6g wrote:
On 25.01.21 07:46, Imperatorn wrote:
Proposed solution:
Archive issues older than 10 years (and maybe some critera based on
latest updated). If they are relevant, it's the authors
responsibility t
On 25.01.21 13:48, Imperatorn wrote:
On Monday, 25 January 2021 at 10:39:14 UTC, Walter Bright wrote:
On 1/24/2021 10:46 PM, Imperatorn wrote:
Imo it's reasonable to close or archive issues that are older than 10
years.
We are not going to do that just because they are old.
If a bug still ex
On 25.01.21 21:03, Paul Backus wrote:
On Monday, 25 January 2021 at 12:48:48 UTC, Imperatorn wrote:
But, at the same time, I guess it could be a bit demoralizing you know?
That's true.
I beg to differ. Open issues are not demoralizing.
Sometimes, reality is demoralizing. That doesn't mean w
On 11.10.21 03:08, Paul Backus wrote:
On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote:
On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote:
Meanwhile @live is in the language, and it's half-baked. Then there's
preview switches that will linger on into perpetuity; DIPs'
On 8/6/22 19:27, Rumbu wrote:
On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
On 8/5/2022 9:43 AM, Max Samukha wrote:
Both "123." and "123.E123" is valid C. For some reason, D only copied
the former.
It's to support UFCS (Universal Function Call Syntax). The idea with C
comp
On 21.09.22 12:39, Mike Parker wrote:
DIP 1043, "Shortened Method Syntax", has been accepted.
The fact that the feature was already implemented behind a preview
switch carried weight with Atila. He noted that, if not for that, he
wasn't sure where he would stand on adding the feature, but he c
On 1/12/23 07:25, Walter Bright wrote:
But also, adding dynamic arrays to C won't make the currently existing
C code safer, the one they care about, because no one's gonna send the
money to update their C89/99/whatever code to C23/26. Even if they
did, there's no guarantee others would as wel
On 05/29/2014 05:35 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
On Wed, 28 May 2014 16:07:08 -0700
Walter Bright via Digitalmars-d-announce
wrote:
Some of the inconsistencies you mentioned and Brian mentioned in his
talk are actually the result of consistencies.
I know this is a bi
On 05/30/2014 02:37 PM, Steven Schveighoffer wrote:
in which case
static if(cond) {
immutable:
}
int x;
should not create x as immutable if cond is true. The current
behavior is not consistent with attribute either.
Ugh, that is really bad. It shouldn't do that. Is that intentional?
enu
On 06/12/2014 02:31 PM, Dicebot wrote:
Compiler can cache return value of function that get called from inside
mixin statement (for a given argument set). As CTFE is implicitly pure
(no global state at compile-time) later generated code can be simply
re-used for same argument set.
>
Re-using it
On 24.04.2017 13:33, Ola Fosheim Grøstad wrote:
On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote:
The trouble is, one cannot look at a piece of code and tell if it
follows the rules or not.
I.e. it's not about it being possible to write memory safe code in C
or C++ (it is), it's ab
On 24.04.2017 19:02, Nick Sabalausky (Abscissa) wrote:
On 04/24/2017 11:17 AM, Timon Gehr wrote:
Also, Java's type system is
unsound.
Not doubting you, but this sounds interesting. Further info or links?
https://dev.to/rosstate/java-is-unsound-the-industry-perspective
On 07.05.2017 19:03, Stanislav Blinov wrote:
On Sunday, 7 May 2017 at 16:57:58 UTC, Andrei Alexandrescu wrote:
Zoom in on the screen for a nice surprise! http://imgur.com/a/qjI4l --
Andrei
I see only unsurprising Jpeg artifacts and not much more :)
It's too low resolution to make anything out.
On 22.05.2017 17:38, Adam D. Ruppe wrote:
On Monday, 22 May 2017 at 15:26:26 UTC, Andrei Alexandrescu wrote:
Yah, didn't want to overload the article (or the discussion) with the
expression/statement distinction. -- Andrei
Yeah, the details might be too much for a general audience (and I
reali
On 18.07.2017 00:44, Andrei Alexandrescu wrote:
On 7/17/17 8:38 AM, Steven Schveighoffer wrote:
What is the resolution of how break statements affect static
foreach/foreach?
We initially allowed break and continue to refer to the enclosing
statement, but upon further consideration we will mak
On 02.09.2017 08:51, Ilya Yaroshenko wrote:
On Friday, 1 September 2017 at 14:03:26 UTC, Martin Nowak wrote:
Glad to announce D 2.076.0.
This release comes with static foreach, many -betterC enhancements,
various phobos additions, an -mcpu=avx2 switch, and lots of bugfixes.
Thanks to everyon
On 04.09.2017 11:00, Timon Gehr wrote:
On 02.09.2017 08:51, Ilya Yaroshenko wrote:
On Friday, 1 September 2017 at 14:03:26 UTC, Martin Nowak wrote:
Glad to announce D 2.076.0.
This release comes with static foreach, many -betterC enhancements,
various phobos additions, an -mcpu=avx2 switch, a
On 04.09.2017 12:46, Petar Kirov [ZombineDev] wrote:
Would you be able to also address
https://issues.dlang.org/show_bug.cgi?id=17798?
https://github.com/dlang/dlang.org/pull/1884
(Any help with getting it to build appreciated -- even the base 'stable'
branch does not compile on my machine.)
On 04.09.2017 16:05, nkm1 wrote:
On Friday, 1 September 2017 at 14:03:26 UTC, Martin Nowak wrote:
This release comes with static foreach
Great! I noticed one small issue, though. When compiled with warnings,
it warns about unreachable code when static foreach in a switch, ...
It works, tho
On 04.09.2017 21:55, Timon Gehr wrote:
On 04.09.2017 16:05, nkm1 wrote:
On Friday, 1 September 2017 at 14:03:26 UTC, Martin Nowak wrote:
This release comes with static foreach
Great! I noticed one small issue, though. When compiled with warnings,
it warns about unreachable code when static
On 07.09.2017 09:48, Rainer Schuetze wrote:
I've added two more:
https://issues.dlang.org/show_bug.cgi?id=17812
https://github.com/dlang/dmd/pull/7127
https://issues.dlang.org/show_bug.cgi?id=17814
https://github.com/dlang/dmd/pull/7126
On 06.04.2018 19:36, H. S. Teoh wrote:
On Fri, Apr 06, 2018 at 05:02:54PM +, Adam D. Ruppe via
Digitalmars-d-announce wrote:
On Friday, 6 April 2018 at 16:57:21 UTC, Jonathan M Davis wrote:
Now, if the contracts ended up in the documentation or something
My documentation generator suppor
On 07.04.2018 00:45, Timon Gehr wrote:
On 06.04.2018 19:36, H. S. Teoh wrote:
On Fri, Apr 06, 2018 at 05:02:54PM +, Adam D. Ruppe via
Digitalmars-d-announce wrote:
On Friday, 6 April 2018 at 16:57:21 UTC, Jonathan M Davis wrote:
Now, if the contracts ended up in the documentation or someth
On 30.07.2018 21:44, Steven Schveighoffer wrote:
On 7/28/18 3:51 PM, Ivan Kazmenko wrote:
Hey,
I wrote a post with my general reflections on using D in competitive
programming.
Mostly compared to C++, since that's what more than 90% of people use
for it.
The post is tailored to cover only th
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 else:
{
auto __temp = pt.x;
doubleMyValue(__temp);
pt.x =
On 05/02/2015 08:28 AM, Andrei Alexandrescu wrote:
I'm just done implementing a pretty cool allocator: FreeTree.
https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/free_tree.d
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_free_tree.html
It's simil
On 05/07/2015 04:49 PM, Andrei Alexandrescu wrote:
- The implementation of 'allocate' appears to be buggy: If no memory
block of a suitable size is found, the entire free tree is released.
(There is only one occurrence of parent.allocate in the code and it
appears right after a call to 'clear'.
On 05/11/2015 01:59 PM, Namespace wrote:
Inspired by ponce idioms list for D I've set up something similar.
There are some themes in D which come up regulary and are discussed to
the vomit. If something is agreed, it gets forgotten sometimes and the
theme disappears into oblivion (for a few month
On 07/30/2015 09:31 AM, thedeemon wrote:
I had this idea for a long time but a recent talk about a real
dependently typed language helped me with nice examples to demonstrate
on. The interpreted part of D is actually dependently typed!
http://www.infognition.com/blog/2015/dependent_types_in_d.ht
On 07/30/2015 05:45 PM, thedeemon wrote:
On Thursday, 30 July 2015 at 13:25:31 UTC, Timon Gehr wrote:
There is no dependent typing here. Failures occur during interpretation.
Type theory doesn't say anything about interpretation and compilation.
You need to consider the type system and the e
On 07/30/2015 06:13 PM, Timon Gehr wrote:
...
The real difference is (roughly!) that the dependently typed interpreted
program always fails if it would fail in any possible execution
(This is ambiguous. What I mean is: If there is some execution in which
it would fail.)
On 08/10/2015 10:48 AM, Martin Nowak wrote:
Glad to announce D 2.068.0.
http://downloads.dlang.org/releases/2.x/2.068.0/
This release comes with many rangified phobos functions, 2 new GC
profilers, a new AA implementation, and countless further improvements
and fixes.
See the changelog for mor
On 08/24/2015 06:09 PM, Adam D. Ruppe wrote:
the if(array) thread
But, this can be surprising if you aren't used to it, since an empty array is
not necessarily null:
[] is null passes, since the literal avoids allocating for nothing, but
[1][1..$] is null fails,
despite the array being empt
On 10/18/2015 09:00 PM, rcorre wrote:
SuperStruct is a struct that acts like a class:
---
struct Square {
float size;
float area() { return size * size; }
}
struct Circle {
float r;
float area() { return r * r * PI; }
}
alias Shape = SuperStruct!(Square, Circle);
// look! polymorp
On 28.03.2016 09:24, 9il wrote:
Hello All,
Sebastian Wilzbach (aka @greenify) starts mir.combinatorics.
Numeric functions:
- `binomial`
Ranges:
- `permutations` RoR
- `cartesianPower` RoR
- `combinations` RoR
- `combinationsRepeat` RoR
RoR - Range of Ranges
PR: https://github.com/DlangScienc
On 06.05.2016 18:58, Kagamin wrote:
On Friday, 6 May 2016 at 14:33:22 UTC, Andrei Alexandrescu wrote:
Added a comment:
https://www.reddit.com/r/programming/comments/4i3h77/some_new_c7_features/d2v5lu6
D has ref variables? Not for a long time though.
D actually does not support ref local va
On 13.05.2016 15:59, Don Clugston wrote:
All that's needed is a very simple bytecode interpreter.
Here is the one I have hacked together:
https://github.com/tgehr/d-compiler/blob/master/interpret.d
This file does both constant folding and byte-code interpretation for
most of the language. I s
On 08.06.2016 03:20, Stefan Koch wrote:
On Friday, 3 June 2016 at 15:46:27 UTC, Stefan Koch wrote:
On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
I will post more details as soon as I dive deeper into the code.
Okay I briefly evaluated the current IR dmd uses for backend
communica
On 11.08.2016 09:48, Walter Bright wrote:
On 8/10/2016 11:36 PM, rikki cattermole wrote:
Perfect :)
The nice thing about this scheme is it can do some things that Rust
can't
What are some of those things?
On 12.08.2016 21:39, Walter Bright wrote:
On 8/12/2016 5:33 AM, Nordlöw wrote:
If this is successfully implemented, what will D not be able to do,
that Rust
can/will?
Have ownership semantics for pointers in more complex data structures.
In D you'll have to do such with ref counted objects.
O
On 21.11.2016 17:55, Piotrek wrote:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:
DIP 1003 is merged to the queue and open for public informal feedback.
PR: https://github.com/dlang/DIPs/pull/48
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
On 19.11.2016 22:16, Dicebot wrote:
DIP 1003 is merged to the queue and open for public informal feedback.
PR: https://github.com/dlang/DIPs/pull/48
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
If you want the change to be approved and have ideas how to imp
On 22.11.2016 20:05, Meta wrote:
On Tuesday, 22 November 2016 at 15:11:04 UTC, Sönke Ludwig wrote:
Am 21.11.2016 um 22:19 schrieb Timon Gehr:
3 is ambiguous.
Can you give an example?
I'm curious as well. I considered that option 3 might be ambiguous but I
managed to convince myself that it
On 23.11.2016 11:15, Sönke Ludwig wrote:
Function declarations don't necessarily have a body, but they might have
contracts. (This is currently not allowed for technical reasons, but it
should/will be.) But this is a rather minor point (usually you don't
want to have contracts without implementa
On 23.11.2016 11:15, Sönke Ludwig wrote:
The more important point is that there is no precedent where {...}{...}
are two components of the same entity, it looks ugly even with the
space-wasting convention where '{' is put on its own line. Not all
contracts are one-liners like in your example abo
On 24.11.2016 12:35, Sönke Ludwig wrote:
Am 23.11.2016 um 21:32 schrieb Timon Gehr:
On 23.11.2016 11:15, Sönke Ludwig wrote:
scope (exit) { assert(n > 0); }
{
n += 1;
}
This is not a counterexample, because the block statement following the
scope statement is not part of
On 24.11.2016 10:47, Kagamin wrote:
As to contracts without body we have
https://issues.dlang.org/show_bug.cgi?id=4720
There is even this: https://github.com/dlang/dmd/pull/3611
(Only works for interfaces and abstract classes though. Note that the
parser didn't change.)
On 24.11.2016 10:24, Kagamin wrote:
On Wednesday, 23 November 2016 at 20:24:13 UTC, Timon Gehr wrote:
Technically, there is an ambiguity (technically, ambiguity means that
there are multiple grammar derivations resulting in the same sentence).
Pragmatically, the greedy parse-the-body-if-possible
On 25.11.2016 22:18, Sönke Ludwig wrote:
Am 25.11.2016 um 12:39 schrieb Timon Gehr:
On 24.11.2016 10:24, Kagamin wrote:
I see no ambiguity even if parsing is not greedy.
import std.stdio;
pragma(mangle,"_D2tt4mainFZ3fooUZv")
void foo()in{ assert(true); }{
writeln("Hello World!");
}
void m
On 12/6/23 17:28, Mike Parker wrote:
One way to do that in D is to use `alloca`, but that's an issue because
the memory it allocates has to be used in the same function that calls
the `alloca`. So you can't, e.g., use `alloca` to alloc memory in a
constructor, and that prevents using it in a
On 12/11/23 20:55, Timon Gehr wrote:
There is the following trick. Not ideal since the length cannot be
inferred, but this successfully injects alloca into the caller's scope.
I see Nick already brought it up.
On 8/30/24 22:36, Dukc wrote:
> He said that going forward, accepting a bad DIP would be less
consequential than it had been in the past once we had editions. In the
worst case, we'd have one thing more to maintain in an intermediate
edition before it was fixed. Maybe that was a calculation
On 8/31/24 17:41, Timon Gehr wrote:
On 8/30/24 22:36, Dukc wrote:
> He said that going forward, accepting a bad DIP would be less
consequential than it had been in the past once we had editions. In
the worst case, we'd have one thing more to maintain in an
intermediate edition before it was
In golf, you try to hit a ball into a hole using the smallest amount of
strokes. In code golf, you try to solve a programming puzzle using the
smallest amount of key strokes. In Phobos golf, you additionally get to
use all of Phobos!
This small competition will during DConf'24. It is hosted on
84 matches
Mail list logo
