On 7/12/2020 2:04 AM, Martin Nowak wrote:
Glad to announce D 2.093.0, ♥ to the 54 contributors.
This release comes with a preview for shared variable initialization, template
instantiation statistics, better Windows support of the install.sh script, and
higher accuracy GC memory options.
On 6/21/2020 8:24 AM, 9il wrote:
[0] https://github.com/libmir/mir-algorithm
[1] http://mir-algorithm.libmir.org/mir_parse.html#.fromString[2]
https://issues.dlang.org/show_bug.cgi?id=20951
[3] https://issues.dlang.org/show_bug.cgi?id=20952
[4] https://issues.dlang.org/show_bug.cgi?id=20953
On 7/9/2020 11:21 PM, Rainer Schuetze wrote:
My first open source project was cv2pdb, a tool that converts old-style
CodeView debug information generated by optlink to a PDB file. Now that
this functionality is more or less available in dmd itself when
compiling to COFF object files, cv2pdb
On 7/7/2020 3:58 AM, 9il wrote:
For a high tech real markets (airspace, automotive, science, military-industrial
complex) having a correct decimal literal parsing has a little but absolutely
mandatory value. If SpaceX is lending a rocket, they want it located on the
platform, something around
On 7/7/2020 6:26 PM, Manu wrote:
The difference is night vs day... VisualD is, by far, like REALLY FAR, the most
mature and useful IDE and debug environment for D.
TL;DR: if you are a D dev, and you use Windows, you should definitely try Visual
Studio + VisualD. I for one couldn't work without
On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote:
On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote:
There is no risk for DMD and DFL to depend on a Mir's Boost licensed library.
If something happens with Mir or Mir change the license, DFL will be able to
fork the required code at any point
Very nice!
Please consider writing an article about your work!
On 7/5/2020 3:35 AM, Walter Bright wrote:
All of DMD, Druntime, and Phobos use Boost, except for Curl and the zip library
(which we probably shouldn't have added).
Also, there are no dependencies on Curl and zip.
We don't distribute the C libraries, we use whatever is on the user's system.
On 7/5/2020 1:56 AM, 9il wrote:
On Sunday, 5 July 2020 at 08:15:53 UTC, Walter Bright wrote:
It doesn't work quite like that. The D Language Foundation controls it.
Andrei, Atila, and myself control it only as far as we DLF empowers us to,
which can change. Official parts of the DMD
On 7/5/2020 12:24 AM, 9il wrote:
On Sunday, 5 July 2020 at 06:23:35 UTC, Walter Bright wrote:
On 7/4/2020 8:09 PM, 9il wrote:
Does the float parsing code require bignum?
Yes. The decimal float parsing requires big integer arithmetic and software
Arbitrary precision or simply a fixed amount
On 7/4/2020 8:09 PM, 9il wrote:
On Saturday, 4 July 2020 at 20:35:48 UTC, Walter Bright wrote:
On 6/21/2020 8:24 AM, 9il wrote:
So excited to finally announce we can correctly parse floating-point numbers
according to IEEE round half-to-even (bankers) rule like in C/C++, Rust, and
others
On 6/21/2020 8:24 AM, 9il wrote:
So excited to finally announce we can correctly parse floating-point numbers
according to IEEE round half-to-even (bankers) rule like in C/C++, Rust, and
others.
Great work! Would you like to add it to dmd?
On 6/20/2020 2:59 PM, Bill Baxter wrote:
Whoa! Page 23 -- a wild Bill Baxter appears! That was unexpected. :-D
--bb
So many contributors - we tried hard to credit where things came from.
On 6/18/2020 1:53 PM, tastyminerals wrote:
On Saturday, 13 June 2020 at 03:16:05 UTC, Walter Bright wrote:
https://dl.acm.org/doi/abs/10.1145/3386323
Many, many thanks to Mike Parker and Andrei Alexandrescu for their endless
hours spent fixing the mess I originally wrote.
Thank you. Printed
On 6/15/2020 8:49 AM, Ben Jones wrote:
Did Eric Niebler lose interest in D? I didn't realize he
was involved early on.
He never was particularly interested in D, he just liked the camaraderie of us
getting together and talking about language design, as we liked it too.
On 6/14/2020 1:22 PM, Timon Gehr wrote:
The only relation to D is that the implementations of the two presented
programming languages are written in D.
Nice!
On 6/12/2020 8:16 PM, Walter Bright wrote:
https://dl.acm.org/doi/abs/10.1145/3386323
Many, many thanks to Mike Parker and Andrei Alexandrescu for their endless hours
spent fixing the mess I originally wrote.
https://www.reddit.com/r/programming/comments/h7vra4
https://dl.acm.org/doi/abs/10.1145/3386323
Many, many thanks to Mike Parker and Andrei Alexandrescu for their endless hours
spent fixing the mess I originally wrote.
On 5/30/2020 4:39 AM, Nick Treleaven wrote:
To preserve this, then please can we have `@safe module foo;`. This would change
the default on a module basis to @safe, but still infer e.g. function template
bodies as @system where necessary. This feature would allow modules from
different
On 5/29/2020 2:38 PM, Adam D. Ruppe wrote:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
The idea is the simple, general rule that:
There's already exceptions to that.
public public void foo() {}
is an error, whereas
public:
public void foo() {}
is not.
Is it really
On 5/29/2020 2:53 AM, solidstate1991 wrote:
Can we get a compiler flag that will enable safe by default for people who might
want it?
It would balkanize the language.
On 5/29/2020 3:36 AM, Ali Çehreli wrote:
Thank you! Which meme did it? :o)
My secret!
On 5/29/2020 4:47 PM, Bastiaan Veelo wrote:
I’m not sure who in this analogy is the Kenny G and who the Clive Davis,
Haha, I was deliberately vague about that, so people could interpret it as they
pleased.
Off topic, and without extending the analogy, I had never heard about Kenny G
He
On 5/29/2020 2:07 AM, Timon Gehr wrote:
It would be great if `@safe:` did not affect declarations that would otherwise
infer annotations.
The idea is the simple, general rule that:
attribute declaration;
attribute { declaration; }
attribute: declaration;
behave the same way.
C++ is
On 5/29/2020 7:22 AM, Paul Backus wrote:
This is sad news. I was excited for @safe-by-default, and had hoped that the
issue with extern(C) could be solved without throwing DIP 1028 away entirely.
I watched a documentary on Clive Davis (famous recording executive) the other
day. He would
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 you think best.
For everyone else, carry on as before.
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.
But why exactly should API breakage not count?
I've addressed exactly this a dozen times or more, to you and others. Repeating
On 5/27/2020 2:34 AM, 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 5/27/2020 3:07 AM, Johannes Loher wrote:
This is a very specific situation. There are a lot of teams / developers
that do not work in this manner. I don't know the numbers so I will make
no statement about what is more common but my personal experience is a
different one.
I've seen larger
On 5/27/2020 3:06 AM, rikki cattermole wrote:
Open to everybody and it can be recorded by Twitch.
I've done the video conferencing many times over the decades. I just don't find
it to be productive. Maybe it's some defect in me.
They usually go something like this:
"Who else is here?"
On 5/26/2020 6:07 AM, Panke wrote:
On Tuesday, 26 May 2020 at 12:20:31 UTC, Johannes T wrote:
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
[..]
Thank you very much for your patience with all the negative feedback.
Yes, good think to stop once in a while and appreciate
On 5/26/2020 5:20 AM, Johannes T wrote:
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
[..]
Thank you very much for your patience with all the negative feedback. I get your
decision to not annotate extern C with @system by default. The biggest issue
with extern @system
On 5/26/2020 12:18 AM, Johannes Loher wrote:
Just think about what the developer's reaction would be in the situation I
described in my last post, when he actually finds the issue.
In your variant, the developer will be questioning why the compiler did not help
him at all with realizing that
On 5/24/2020 3:40 AM, Stefan Koch wrote:
The distinction is that you can find a slapped on trusted with a grep.
It's just as easy to use grep to *not* find @trusted.
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.
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 example of currently compiling and correctly
On 5/26/2020 9:31 AM, Bruce Carneal wrote:
Currently a machine checked @safe function calling an unannotated extern C
routine will error out during compilation. This is great as the C routine was
not machine checked, and generally can not be checked. Post 1028, IIUC, the
compilation will go
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 5/25/2020 7:04 PM, Johannes Loher wrote:
Now let's compare the two different options:
1. With DIP1028 in its current form, the code will compile and a memory
corruption will actually happen. The problem might be extremely difficult to
track down for the developer because he has no clues
On 5/24/2020 5:56 PM, Timon Gehr wrote:
It's only greenwashing if it's misleading. Putting @safe is a lie, putting
@trusted is honest.
It is not honest unless the programmer actually carefully examined the interface
and the documentation to determine if it is a safe interface or not. For
On 5/23/2020 5:13 AM, Steven Schveighoffer wrote:
And let's be honest here, if you are OK with it, putting @trusted: at the top of
your extern(C) functions is fine with me. At least that's not a lie.
@trusted says the interface to the function is safe. If the programmer did not
actually check
On 5/24/2020 2:29 AM, Panke wrote:
I've always understood that the @safe,@trusted,@system machinery provides the
following guarantee once all holes are fixed:
If I have a memory corruption in my code than I need to only look at the
@trusted and @system parts to find it.
Marking whatevs
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 do, for various reasons. I've seen it a
I infer your position is the idea that putting @trusted on the declarations
isn't greenwashing, while @safe is.
I can't see a practical difference between:
@safe extern (C) void whatevs(parameters);
@trusted extern (C) void whatevs(parameters);
Both require that whatevs() provide a safe
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 un-annotated declarations cause a compile time error, it is highly
On 5/22/2020 10:25 AM, Timon Gehr wrote:
With the o/b system `free` might actually work out OK
free(new int);
I did mention in the documentation that when using different memory allocators,
mixing them up will not be detected. You'd have to declare the allocators using
specific pointer
On 5/23/2020 4:26 AM, Faux Amis wrote:
Just a suggestion, but sometimes matters are best discussed over audio/video.
Would having a public teams/zoom/.. meeting be helpful?
I would definitely listen/watch; even if I were muted and could only chat maybe.
You're right, and that is the whole
On 5/22/2020 10:33 AM, rikki cattermole wrote:
To me at least, this butchers @safe/trusted/system into a system that is near
useless for guarantees for an entire program.
It never attempted to guarantee safety in code that was never compiled with a D
compiler. It's impossible to do that. No
On 5/22/2020 10:54 AM, Atila Neves wrote:
BTW, you should fix that invalid attribute, freeing a pointer is never @safe
unless you can guarantee nobody else has a copy of that pointer (and
considering it's passed by value, the CALLER still has that pointer!)
You're completely right.
@live is
On 5/21/2020 4:45 PM, H. S. Teoh wrote:
This makes it sound like you think that those who disagree with you
disagree with @safe by default. That is not the case.
I'm sure you all know what I'm talking about.
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 the best solution.
I can see that happening. A simple example
I have made these points before, but I'll summarize them here
for convenient referral.
The proposed amendment to Safe by Default is:
"Extern C and C++ functions without bodies should be @system
by default."
The rationale is that since the compiler cannot check them for @safe,
they should
On 5/21/2020 2:41 PM, Steven Schveighoffer wrote:
I even put forth a completely ignored compromise solution that would have solved
the problem and allowed extern(C) functions to be considered @safe by default:
On 5/21/2020 2:45 PM, bachmeier wrote:
On Thursday, 21 May 2020 at 20:48:18 UTC, Walter Bright wrote:
On 5/21/2020 10:03 AM, bachmeier wrote:
Walter makes decisions based on his mood on a particular day
That's uncalled for.
Regional variation in English? Translation: You make your decisions
On 5/21/2020 2:44 PM, Joseph Rushton Wakeling wrote:
One concern here is that these responses are scattered across different parts of
a long discussion thread. So it probably would be a good idea for the
acceptance to be accompanied by an explanation of what the major objections were
to the
On 5/21/2020 10:26 AM, Steven Schveighoffer wrote:
Agree. I will not be participating in the DIP process from now on. It is a
complete waste of time. Walter should just make the changes he wants and not
bother with the facade of discussion.
Many replies to you, Steven:
On 5/21/2020 10:03 AM, bachmeier wrote:
Walter makes decisions based on his mood on a particular day
That's uncalled for.
On 5/21/2020 11:36 AM, H. S. Teoh wrote:
I'd even grant that Walter, being BFDL, can make whatever arbitrary
decisions he wants, but at the very least acknowledge the existence of
the rest of us. "Accepted without comment" amounts to denial that we
even exist, considering how much feedback was
On 5/21/2020 9:14 AM, Seb wrote:
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
"without comment" - even though there were a lot of
On 5/14/2020 9:57 AM, Iain Buclaw wrote:
As of last week (7th May), GCC 10.1 has now been released.
Thank you, Iain, for your hard and fantastic work!
On 4/28/2020 9:12 AM, Seb wrote:
// Internal Compiler Error: type int[] cannot be mapped to C++
There have been multiple attempts to fix this, the latest one is
https://github.com/dlang/dmd/pull/8120.
Now, that dmd comes with the (experimental) -H flag for C++ header generation,
maybe there's
On 4/25/2020 4:11 AM, Jacob Carlborg wrote:
I have previously downloaded the DConf videos. I sent them to Mike for him to
upload.
Thank you! You have certainly saved the day here!
Please do an AMA on the Reddit article!
On 3/16/2020 12:36 PM, Walter Bright wrote:
Oh, I'm quite in favor of an online conference. Anyone who wants to step up and
take charge of it has my support.
Everyone, I've started a new thread for an online DConf. Please post there
instead of here. Thanks!
Starting a new thread for this instead of hijacking others.
On 3/16/2020 9:15 AM, bachmeier wrote:
"Have an online conference" isn't especially helpful. There haven't been any
detailed proposals, and Walter hasn't said anything one way or the other about
doing something online.
Oh, I'm quite in favor of an online conference. Anyone who wants to step
On 3/12/2020 9:18 AM, Patrick Schluter wrote:
[...]
C'mon, fellows. There are PLENTY of places online where you can discuss this.
But this forum is for D.
On 3/7/2020 9:36 PM, Murilo wrote:
What about rescheduling it for later this year? I'd suggest September(summer).
The coronavirus plague could easily last for a year.
On 3/7/2020 2:49 PM, matheus wrote:
On Saturday, 7 March 2020 at 21:58:06 UTC, Adam D. Ruppe wrote:
Let's do a little online thing instead! We could do a chat room, livestream,
blog, you know stuff like that.
In fact this is something I'd like to see here, and I even proposed the same
thing
On 3/7/2020 1:13 PM, Ernesto Castellotti wrote:
Right choice, prevention is better than cure!
Of course I am sad for the cancellation of the DConf, but unfortunately it could
not have been done differently.
I hope it can be rescheduled after the end of this terrible emergency.
I'm pretty
On 3/2/2020 11:17 AM, Sönke Ludwig wrote:
As of yesterday, code.dlang.org now points to a more powerful dedicated server
that can host the DUB registry without the danger of freezing due to excessive
swapping - this is what happened on the 26th last month [1].
Wonderful news!
On 2/28/2020 5:00 PM, Andrei Alexandrescu wrote:
Walter, Mike, and I are happy to announce that our paper submission "Origins of
the D Programming Language" has been accepted at the HOPL IV (History of
Programming Languages) conference.
https://hopl4.sigplan.org/track/hopl-4-papers
Getting a
On 2/27/2020 3:44 AM, aliak wrote:
Btw: Swift does this for string interpolation and it works very well ->
https://www.hackingwithswift.com/articles/178/super-powered-string-interpolation-in-swift-5-0
I don't know Swift, but this looks like the "generate strings and concatenate
them"
On 2/27/2020 6:32 AM, Petar Kirov [ZombineDev] wrote:
I'm not sure where exactly you draw the line, but I would say that C# follows
C's syntax about as much as D does.
C# is very different from C. D is not so different, and close enough that
DasBetterC is very viable. Hindsight being 20/20,
On 2/27/2020 1:45 AM, Rainer Schuetze wrote:
The string buffer could also be stack allocated or manually managed with
malloc/free by the string interpolation type.
It's quite a big deal to make that work, and does not address the inherent
inefficiency of it.
printf, for all its faults, is
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 strings to be generated
On 2/27/2020 12:27 AM, Petar Kirov [ZombineDev] wrote:
I'm well aware that allocation is inevitable if we want this behavior. My
argument is that this behavior is so ubiquitous that not following it would be
surprising to much more people, than if D didn't follow C's Usual Arithmetic
On 2/26/2020 10:38 PM, FeepingCreature wrote:
On Thursday, 27 February 2020 at 03:50:35 UTC, Walter Bright wrote:
On 2/26/2020 4:46 PM, Adam D. Ruppe wrote:
But DIP1027 had a fatal flaw: it made type safety impossible.
I don't see how that is true.
Because it turned a format string
On 2/26/2020 4:46 PM, Adam D. Ruppe wrote:
But DIP1027 had a fatal flaw: it made type safety impossible.
I don't see how that is true.
On 2/26/2020 5:19 AM, Steven Schveighoffer wrote:
We can do it without specifying that it's a template or the name of that
template.
That isn't what was proposed. I seriously suggest preparing a DIP. Bits and
pieces spread out over multiple posts and multiple threads is not working.
But
On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote:
In all other languages with string interpolation that I'm familiar with, `a` is
not passed to the `i` parameter.
All rely on a garbage collected string being generated as an intermediate
variable.
On 2/26/2020 4:18 AM, FeepingCreature wrote:
But to be thrice fair, Adam/Steven's proposal would work with the minor
extension [...]
So would DIP1027.
You can also write:
print(format(i"I have $apple_cnt apples"));
void print(string s) { print_many(s); }
and get the behavior you're looking for.
On 2/26/2020 2:02 AM, Juraj Mojzis wrote:
void print_many(string msg, int cnt = 1) {
foreach(i; 0 .. cnt) writeln(msg);
}
int apple_cnt = 4;
print_many(i"I have $apple_cnt apples.");
expected: I have 4 apples.
Doing what you want would require a runtime GC allocated string.
On 2/24/2020 4:07 PM, Steven Schveighoffer wrote:
To ensure that it cannot be intercepted.
See my reply to H.S. Teoh which addresses this.
On 2/25/2020 9:44 AM, H. S. Teoh wrote:
On Mon, Feb 24, 2020 at 10:54:34PM -0800, Walter Bright via
Digitalmars-d-announce wrote:
[...]
Writing that an implementation must refer to specific templates
implies that the behavior is customizable by the user via modifying
those templates.
I think
On 2/25/2020 7:04 AM, Steven Schveighoffer wrote:
On 2/25/20 1:54 AM, Walter Bright wrote:
Were you proposing that an i"" be a different type? (DIP 1027 did not
assign a type to it at all.)
No, I proposed that the first element of the tuple be specified as a new
spec-defined ty
On 2/25/2020 8:04 AM, Arine wrote:
Is this really the line of thinking going on here? It seems Walter has these
arbitrary rules he's following which led up to the impractical and buggy
solution that was DIP1027. Rules aren't meant to be followed blindly.
See what I mean about "no consensus
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);
f(i"hello $a"); // silent unwanted bahviour.
?
It is lowered to:
On 2/24/2020 8:24 PM, FeepingCreature wrote:
The behavior of formatting strings is *currently*
deferred to a template (std.format and co). This lets us do important decisions
at compiletime, like writing the format string to a file or a string buffer
piecewise without allocating memory. Why
On 2/24/2020 2:45 PM, Steven Schveighoffer wrote:
My inference of the discussion about this in the n.g. was the templates would
be used so users could customize the behavior to be whatever they wanted.
By accepting a different type from string. In other words, an overload.
This means you can
On 2/24/2020 1:45 PM, Steven Schveighoffer wrote:
Our proposal is even more restrictive, as the template and its API are actually
defined by the language.
API is defined by the language, but not the behavior.
No. It's overloading, not AST macros. How can an overload affect the AST other
On 2/24/2020 12:19 PM, Steven Schveighoffer wrote:
How can you possibly arrive at this conclusion? We lower to templates all the
time.
The language is nowhere defined as lowering to specific templates. There are
indeed some lowerings to templates in the implementation of the language, but
On 2/24/2020 11:45 AM, Adam D. Ruppe wrote:
On Monday, 24 February 2020 at 19:35:16 UTC, Walter Bright wrote:
Having the compiler lower string interpolation to some hidden template is -
AST macros. We're not doing AST macros.
This is untrue.
Hidden user-defined semantics are not for D.
We
On 2/24/2020 9:24 AM, Arine wrote:
No [...]
Using unprofessional language will result in your posts being deleted. Please
stop.
Having the compiler lower string interpolation to some hidden template is - AST
macros. We're not doing AST macros.
Hidden user-defined semantics are not for D. Every language I'm familiar with
that supports it wound up with users creating their own completely undocumented
personal language
On 2/24/2020 12:43 AM, Robert M. Münch wrote:
Out of curiosity, how and who makes such a decision? Is there a voting? Is there
a committee? Is there a structured pro/con overview and highlight of
blocking-points that need to be resolved?
I talk it over with Atila after the review threads are
Looking forward to your success there!
On 2/21/2020 3:52 PM, stewart wrote:
This is great!
I've been pushing D in my workplace, which is full of Python programmers and
this is another good example I can use showing why D rocks. I'm going to
introduce this and then push hard the line "Now you
On 2/5/2020 3:50 AM, IGotD- wrote:
I must say that it is summarized very well. Especially that it is focusing
implementing the latest cool feature instead of stability.
Non-specific complaints are useless. If you have specific issues, post the
bugzilla numbers. If they aren't in bugzilla, add
https://www.reddit.com/r/programming/comments/eyzrm9/d_as_a_c_replacement_the_art_of_machinery/
https://theartofmachinery.com/2019/04/05/d_as_c_replacement.html
201 - 300 of 15506 matches
Mail list logo
