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 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
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
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
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
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 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
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
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
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 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
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
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
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
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
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() {
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:
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
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
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
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;
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 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
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
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
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
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
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
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 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
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
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
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 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 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
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
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
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 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
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 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
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
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
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 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 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,
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 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,
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
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
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
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
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 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
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
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
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 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 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
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
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 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
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 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 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
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
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
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:
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!
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
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
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!
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
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 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
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
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
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 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?
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
digitalmars-d-announce@puremagic.com wrote:
Some of the inconsistencies you mentioned and Brian mentioned in his
talk are actually the result
80 matches
Mail list logo
