On 1/7/2020 6:31 PM, Manu wrote:
It will still do that, either now... or later. So, why wait?
Because customers have their own schedules.
On 1/6/2020 10:17 PM, Manu wrote:
Well it was a preview for an unaccepted DIP, so it could have been
withdrawn. I guess I have increased confidence now, but it still seems
unnecessary to delay.
Preview means for accepted DIPs as well when they break existing code.
Don't really have a
On 1/3/2020 3:41 AM, Manu wrote:
We've already had this -preview for quite a while; I have enabled it
in an experimental context, but I don't tend to write and deploy code
that depends on future-features. I stick to the current language when
writing code I intend to share.
Do you have some sense
On 1/2/2020 11:31 PM, Manu wrote:
Okay, although I don't really understand; if we have accepted the
feature, but we don't enable the feature... then nobody will use it,
and no code will be written that's compatible.
This kinda seems like a future-acceptance?
Nobody enables `-preview`s.
Those
On 1/2/2020 4:17 AM, Manu wrote:
On Thu, Jan 2, 2020 at 7:45 PM Walter Bright via
Digitalmars-d-announce wrote:
On 1/2/2020 12:01 AM, Manu wrote:
Quick quick, we need a PR to issue deprecation messages for those
invalid read/writes! :)
It's already been merged!
https://github.com/dlang
On 1/2/2020 12:01 AM, Manu wrote:
Quick quick, we need a PR to issue deprecation messages for those
invalid read/writes! :)
It's already been merged!
https://github.com/dlang/dmd/pull/10209
Some really fast work there :-)
On 1/1/2020 9:53 PM, Manu wrote:
On Thu, Jan 2, 2020 at 3:40 PM Mike Parker via Digitalmars-d-announce
wrote:
DIP 1024, "Shared Atomics", was accepted without comment.
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1024.md
This has been a long time coming!
A New Year's
On 12/5/2019 5:07 PM, Murilo wrote:
Hi everyone. I've spent the last weeks working on a program which is able to
read and understand text from an image file(OCR) by using a rudimentary neural
network after training with a large amount of images(I made them myself,
manually). It even shows a
On 11/27/2019 6:35 AM, Ernesto Castellotti wrote:
With BetterC everything seems to be working fine, now it's time to create a
framework for using D on microcontrollers!
Yay!
On 11/20/2019 1:06 AM, Les De Ridder wrote:
Will this talk be recorded?
They usually are, but sometimes something goes wrong with the camera.
Title
A Unifying Abstraction for Async in C++
Abstract
Async in C++ is in a sad state. The standard tools — promises, futures, threads,
locks, and std::async — are either inefficient, broken, or both. Even worse,
there is no standard way to say _where_ work should happen. Parallel algorithms,
On 11/7/2019 2:16 AM, Ethan wrote:
Note that my schedule over the next year will probably preclude me from having
the time to prepare a talk. So there'll likely be one slot that I usually take
waiting to be filled by someone with great new ideas.
This is something I'd personally prefer in
On 11/6/2019 7:44 PM, bachmeier wrote:
Also, it's low cost to submit, so there's no reason not to do so. Even if it's
turned down, you don't have much to lose. You'd obviously have more information
about the proposals than I do, but there must not have been many given how few
presentations
On 11/1/2019 2:57 AM, Mike Parker wrote:
BOSKorea has a few Korean programmers who had never used D before joining the
company. Now future hires can take the DLang Tour in Korean. Thanks to Mathias
Lang for initiating the translation effort.
https://tour.dlang.org/tour/en/welcome/languages
On 10/31/2019 2:51 AM, SealabJaster wrote:
On Thursday, 31 October 2019 at 07:38:46 UTC, Walter Bright wrote:
Looks like a very nice initiative! Looking forward to more!
A thought - host it on github? That way people can easily contribute
suggestions to it. You'd be in charge, of course
Looks like a very nice initiative! Looking forward to more!
A thought - host it on github? That way people can easily contribute suggestions
to it. You'd be in charge, of course, with what to do with those suggestions.
On 10/28/2019 2:38 PM, Ben Jones wrote:
Just for context, here's a paper arguing restrict without tooling is a bad idea:
http://people.cs.pitt.edu/~mock/papers/clei2004.pdf . Having the compiler
enforce it changes the game substantially, I think.
I've always known it was a bad idea (not just
On 10/28/2019 12:23 PM, jmh530 wrote:
Is there a connection between this DIP and the restrict qualifier in C? This DIP
basically ensures that in @safe code, if a piece of data is accessed only
through scope pointers, then there must be only one mutable pointer to said data
or they are all
Reddit:
https://www.reddit.com/r/programming/comments/djgsdy/d_at_20_hits_and_misses/
On 10/17/2019 12:24 PM, Dennis wrote:
On Monday, 23 September 2019 at 17:49:12 UTC, H. S. Teoh wrote:
Will this talk be posted somewhere like Youtube afterwards?
It's up now!
https://www.youtube.com/watch?v=p22MM1wc7xQ
Slides: https://digitalmars.com/articles/hits.pdf
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/
And on the programming subreddit:
https://www.reddit.com/r/programming/comments/di954b/vision_of_ds_future/
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
On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
- adding another method to a class, marked @nogc, and (maybe) deprecating the
previous method is seen as 'annoying', also if it's a _clear_ improvement over
the actual situation (you can write _better_ code with that in place compared to
the
On 10/6/2019 2:59 AM, Paolo Invernizzi wrote:
Well, so there's hope that _very little_ improvements will be merged, in a way
or another? I mean, there's some sort of policy for things like that:
https://github.com/dlang/phobos/pull/6730
Frankly speaking, the actual situation it's a little
On 10/5/2019 6:58 AM, Seb wrote:
Phobos is essentially dead/frozen (feature-wise).
I beg to disagree. A couple cases in point:
https://github.com/dlang/phobos/pull/7211
which is a re-imagining, rethinking of hexString.
and:
https://github.com/dlang/phobos/pull/7130
On 9/27/2019 4:18 AM, RazvanN wrote:
On Friday, 27 September 2019 at 10:39:42 UTC, M.M. wrote:
On Friday, 27 September 2019 at 09:26:22 UTC, RazvanN wrote:
Hello all,
Alexandru Militaru's work "D for a @safer Linux Kernel" [1] has just been
accepted for a poster presentation at APLAS [2]. We
On 9/23/2019 3:01 PM, H. S. Teoh wrote:
On Mon, Sep 23, 2019 at 02:55:00PM -0700, Walter Bright via
Digitalmars-d-announce wrote:
On 9/23/2019 10:49 AM, H. S. Teoh wrote:
Will this talk be posted somewhere like Youtube afterwards?
Yes, though sometimes it doesn't due to various failure
On 9/23/2019 12:38 AM, Peter Jacobs wrote:
On Sunday, 22 September 2019 at 19:40:48 UTC, Walter Bright wrote:
I'll be speaking at the Northwest C++ Users's Group on Oct 19.
https://nwcpp.org/
That page says "Oct 16th, 2019 at 7:00 PM".
Oops, you're right!
On 9/23/2019 10:49 AM, H. S. Teoh wrote:
Will this talk be posted somewhere like Youtube afterwards?
Yes, though sometimes it doesn't due to various failure modes of the camera and
operator :-)
I'll be speaking at the Northwest C++ Users's Group on Oct 19.
https://nwcpp.org/
Work began on the D programming language 20 years ago. A huge part of language
design is looking at the past for what worked and what didn’t, and divining
future trajectories so the language can be where the
On 9/3/2019 1:22 AM, Manu wrote:
Huzzah!
I like to think std::string and std::vector are a pretty big deal too ;)
They are. Congrats!
On 8/18/2019 1:40 PM, Robert M. Münch wrote:
Walter, you might not remember, but we once met at an exhibiton in Wiesbaden (I
think), Germany, where you were with Symantec for the C++ compiler and we had a
short chat. And I once tested a bunch of C++ compilers for a German computer
magazine...
On 8/8/2019 5:33 PM, 12345swordy wrote:
What does this mean for the future of the D language?
Nothing, since D is now fully Boost Licensed. But it's important for those
interested in how D came about.
https://finance.yahoo.com/news/broadcom-buy-symantec-enterprise-division-201706500.html
It's the end of an era. Symantec bought my company, Zortech, and now is bought
in return. The D community, and myself personally, owe a debt of gratitude to
Symantec.
Thank you, Symantec!
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.
On 7/20/2019 5:42 AM, Sebastiaan Koppe wrote:
Anyway my question is whether the ownership and borrowing semantics ever gets
applied to non-pointers?
Currently, no. The programmer would be expected to include the correct
copyctor/opAssign/destructors which would take care of it.
We're likely
On 7/17/2019 12:11 PM, Olivier FAURE wrote:
On Tuesday, 16 July 2019 at 06:12:42 UTC, Walter Bright wrote:
Now I just have to deliver the goods!
Lately, I've been thinking about the possibility of an alternative ownership
system for D, one that would be radically different from what you're
On 7/15/2019 7:58 AM, Mike Parker wrote:
The blog:
https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/
Reddit:
https://www.reddit.com/r/programming/comments/cdifbu/ownership_and_borrowing_in_d/
Hacker News:
https://news.ycombinator.com/item?id=20441519
On 7/15/2019 8:52 PM, rikki cattermole wrote:
Wonderful quote from you Walter!
The careful reader will notice something peculiar in what I wrote: “as if”.
What do I mean by that weasel wording? Is there some skullduggery going on?
Why yes, there is. Computer languages are full of “as if”
On 7/15/2019 7:07 PM, Mike Franklin wrote:
Thank you, Walter. This is very exciting. I've said that if I could have my
ideal language, it would be Dust, and now I just might get it :)
Now I just have to deliver the goods!
Now on the front page of Hacker News at number 9!
https://news.ycombinator.com/news
Thank you, Martin!
Hacker News article direct link:
https://news.ycombinator.com/item?id=20266566
On 6/18/2019 12:05 PM, Dragos Carp wrote:
AID GmbH (https://aid-driving.eu) a subsidiary of AUDI AG is looking for
experienced D-evelopers in Munich.
It's on the front page at #9 of Hacker News at the moment!
https://news.ycombinator.com/news
On 6/12/2019 4:51 PM, Martin Nowak wrote:
Glad to announce the first beta for the 2.086.1 point release, ♥ to the
20 contributors.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.086.1.html
As usual please report any bugs at
https://issues.dlang.org
-Martin
Thank you,
On 6/11/2019 11:03 PM, Nick Sabalausky (Abscissa) wrote:
My grandfather and *at least* one (to my immediate knowledge) of my great uncles
were WW2 veterans. For all I know, they could have been D-Day, or any other
involvement, but nobody in our family would ever know because they made a point
On 6/11/2019 5:11 PM, Murilo wrote:
Thanks, I tried it here in my country and people ignored both the Dlang event
and D Day remembrance. I tried to gather everyone in a pub to give a talk but no
one came. By the way, you are Walter Bright, the father of Dlang, it is such and
honor to get
L__L|
/\
/\
/ ___\
\ \#/ \/ \ /
\|#| O| O|#\
|#L _L__ #|
|###| |##|
/###/ /##|
/###/ /##/
/###/___/###/
/###/
/##/
/ \
\ /
_ \ /__
|__/ |__/
On 6/5/2019 7:45 PM, Kaylan Tussey wrote:
And If
possible, i wouldn't mind knowing if having that original image would cause some
legal problems. I mean that's Walters work right?
It is my work, and feel free to use it!
On 6/9/2019 9:32 AM, Aurélien Plazzotta wrote:
Perhaps, someone would be interested to turn the logo into a 2D or 3D comics for
marketing purposes, for forums like reddit.
https://twitter.com/DlangGuy
https://twitter.com/hashtag/dlangman?src=hash
https://www.reddit.com/r/programming/comments/bxv5tf/dconf_2019_binding_rvalues_to_ref_parameters/
https://www.reddit.com/r/programming/comments/bxull9/frictionless_d_adoption_for_the_masses/
https://www.reddit.com/r/programming/comments/bwz91d/different_memory_allocation_strategies_in_d/
On 5/27/2019 6:46 PM, 9il wrote:
Does DMD still use x87 for float/double on other targets?
Yes - Win32 and FreeBSD32.
We'll see how this goes, and if it's good we can do the rest.
32 Bit Linux now uses XMM registers for float and double rather than the x87.
This should substantially speed up routine float and double processing.
SIMD vector operations, however, are still not support on 32 bit Linux code
because of issues with 16 byte stack alignment.
This means that
This is getting way off topic, guys.
It's still a good idea, however, to acknowledge the real D-Day veterans on any
event on D-Day.
On 5/24/2019 9:00 PM, Mike Franklin wrote:
On Saturday, 25 May 2019 at 03:22:50 UTC, Murilo wrote:
On the 6th of June(6/6) we celebrate the D day on Normandy, but I have decided
to turn it into our own holiday to celebrate the D language.
I'm sure you mean well, but I will be spending D-Day
If all access to internals is returned by ref, those lifetimes are restricted to
the current expression.
On 5/17/2019 11:45 AM, Jonathan M Davis wrote:
It is my understanding that DIP 1000 really doesn't track lifetimes at all.
It just ensures that no references to the data escape. So, you can't do
something like take a scope variable and put any references to it or what it
refers to in a
On 5/17/2019 10:26 AM, Meta wrote:
I'll try to reduce it further, but this example is already as reduced as I could
make it while still having the same structure as my actual code.
It doesn't need to have the same structure. It just needs to exhibit the
problem.
On 5/16/2019 9:50 PM, Meta wrote:
Walter, can I get you to take a look at this post I made a few months ago, and
the contained example? I feel that this is a case that *should* definitely work,
but I'm not sure if it can *currently* work - and so far, nobody else seems to
be either, save for
On 5/16/2019 10:24 AM, H. S. Teoh wrote:
More and more, I'm becoming convinced that this sort of usage of
function overloading is an anti-pattern. It should instead be written
as something like this:
I agree. And there at least you can find all the uses.
Good idea. But looks like Nicholas
On 5/15/2019 11:09 AM, H. S. Teoh wrote:
*Why* putting 'private' on a field member makes toHash unsafe, is beyond
my ability to comprehend.
That's because the reduced version isn't a reduced version. It imports a vast
amount of other code.
On 5/15/2019 12:21 AM, Dukc wrote:
Could be worth a try even without docs, but in the long run we definitely need
some explaining.
True, but I've tried fairly hard with the error messages. Please post your
experiences with them.
Also, there shouldn't be any caveats with using it. If it
On 5/14/2019 11:49 PM, Dukc wrote:
About -DIP1000, I sure want to use it. But is there currently any practical way
to learn it's usage without researching compiler source code?
This is a good start:
http://dconf.org/2017/talks/bright.html
https://github.com/dlang/phobos/pull/6931
This is a major milestone in improving the memory safety of D programming.
Thanks to everyone who helped with this!
Time to start compiling your projects with DIP1000, too!
On 5/14/2019 6:34 PM, Mike Franklin wrote:
If bool is clowny, and someone's willing to do something about it,
why discourage them from doing so?
Because core language changes necessarily consume a lot of other peoples' time,
not just yours. This extends well beyond just the core developers -
On 5/13/2019 12:40 AM, Johannes Loher wrote:
Thanks for the links, Walter. I still think that we should make them
easily available from either the website or the forums. I believe Mike
already mentioned that during the AGM. Is there anybody already working
on that?
I don't know if there's
A request for this was made at DConf (I think by Nicholas) and we're already
doing it:
https://www.digitalmars.com/NewsGroup.html
Just click on the items under the "Archive" column. It's all there, back to the
first post. It's organized as one page per thread.
The web pages are created by
On 5/11/2019 7:27 PM, Mike Franklin wrote:
I think Walter is conflating how bool is stored in memory with its
semantics.
That's exactly what I'm deliberately doing.
I'm currently considering using D's rich modeling features
to create a new boolean type that behaves more like a boolean and
On 5/3/2019 3:59 AM, Ali Çehreli wrote:
Decidedly low tech and with broken links but here they are. This one is of
Walter and Seb:
http://acehreli.org/photo/dconf_2018/DSC02662.html
Thank you, brings back lots of great memories!
Thank you, Iain Buclaw!
https://www.phoronix.com/scan.php?page=news_item=GCC-9.1-Compiler-Released
https://www.reddit.com/r/programming/comments/bk6rk2/gcc_91_released_as_huge_compiler_update_with_d/
https://news.ycombinator.com/
On 4/20/2019 7:16 AM, Martin Nowak wrote:
Glad to announce the first beta for the 2.086.0 release, ♥ to the 52
contributors.
Martin, thank you for the invaluable but thankless job of managing the releases!
On 3/26/2019 12:57 AM, Marco de Wild wrote:
I've also tried to use pure, but (ironically) I found it harder to use. I think
it's easier to understand when an object will be mutated or not than to predict
whether there are side effects.
Using pure is indeed hard. One has to make a change in
Many thanks to Sebastian Wilzbach, Nicholas Wilson, Mike Franklin, and others!
It's been a long and often frustrating endeavor, but we made it and I'm very
pleased with the results.
On 3/18/2019 8:55 AM, Robert M. Münch wrote:
Typo in Walter's abstract: ... "D supports a number of techniques for allocating
meory." => memory
I should stop trusting the cat to review my work.
On 3/7/2019 9:27 AM, Mike Parker wrote:
On Thursday, 7 March 2019 at 15:45:50 UTC, Atila Neves wrote:
C++ is hard:
https://atilaoncode.blog/2019/03/07/the-joys-of-translating-cs-stdfunction-to-d/
Reddit:
On 2/27/2019 3:27 AM, Jacob Carlborg wrote:
[...]
Please start another thread.
On 2/26/2019 2:32 AM, Jacob Carlborg wrote:
What about the __mutable proposal [1]?
[1] https://github.com/dlang/dmd/pull/8315
It hasn't been approved yet, and please start another thread if you want to
discuss it.
On 2/25/2019 7:17 PM, Manu wrote:
break my DIP
The review process is not about "why not add this feature" , but "why should we
have this feature".
Additionally, it is most assuredly about finding flaws in it. Isn't it best to
find out the flaws before going further with it than finding
On 2/25/2019 7:17 PM, Manu wrote:
I'm literally astonished that it's been agreed it's fine that
a copy constructor can mutate the source... and I can't help but draw
contrast to the exact same sorts of arguments that people were using
to break my DIP,
Mutating the lvalue ref was not the issue,
On 2/25/2019 3:05 PM, Olivier FAURE wrote:
On Monday, 25 February 2019 at 22:45:38 UTC, Olivier FAURE wrote:
For the same reason C++'s std::shared_pointer uses a non-const copy constructor.
Wait, no, I just checked, std::shared_pointer's copy constructor is const, even
though it changes
On 2/25/2019 10:44 AM, Andrei Alexandrescu wrote:
On 2/25/19 1:39 PM, Jacob Carlborg wrote:
On 2019-02-25 17:31, Andrei Alexandrescu wrote:
The proposers (Razvan and myself) and Walter (the reviewer) do not know how
to make DIP 1018 better.
That shouldn't justify accepting a DIP that might
On 2/25/2019 6:55 PM, Andrei Alexandrescu wrote:
If there's something else I can do to atone, please let me know.
Pistols at dawn?
Or better yet, why don't I buy both of you a beer at DConf?
On 2/25/2019 8:22 AM, H. S. Teoh wrote:
I disagree. Logical const means the outside world can't tell that the
object has changed, because only a constant value is ever seen from
outside. This is the basis of lazy initialization (which is part of the
concept of lazy evaluation), an important
On 2/25/2019 7:45 AM, Atila Neves wrote:
I have no idea what people are talking about when they mention on this forum
that D's const is useless. Nearly every function parameter in my code is `in`.
Nearly every variable declaration uses `const` instead of `auto`, the main
exception being when a
On 2/25/2019 3:09 PM, Olivier FAURE wrote:
Yes, this DIP was fast-tracked. Yes, this can feel unfair. And yet, it makes
sense that it was fast-tracked, because it fits a priority of the project owners
(C++ interoperability + reference counting) and project owners are allowed to
have
On 2/25/2019 6:26 PM, Andrei Alexandrescu wrote:
I haven't heard the final decision from Walter yet, but I proposed that in the
interest of quality, we will go through the customary two weeks reviews with DIP
1018.
I approved it.
On 2/24/2019 8:04 PM, Manu wrote:
1. make code easier to understand?
const code is self documenting and protective against modification by
issuing the user helpful error messages.
I've had many people tell me they mean transitive const when they use const in
C++. That is not self
Your DIP, and nobody else is going to do it, so it falls to me.
BTW, everyone should expect the DIP process to be brutal. It has to be, we're
long past the stage where we can allow misshapen stuff to get into the language.
Nobody was very kind with my bottom type DIP :-)
You should read the
I agree with your point that C++ const can be used in a lot more places than D
const. Absolutely true.
Missing from the post, however, is an explanation of what value C++ const
semantics have. How does it:
1. make code easier to understand?
2. prevent common programming bugs?
3. help with
The problem with C++ const is it only goes one level, i.e. what I call
"head-const". If you pass a T to a const parameter, anything T references
remains mutable. It's more of a suggestion than anything reliable or
enforceable. It only works if your data structures are simple aggregates, not
Thanks for letting me know you're abandoning the rvalue ref DIP. I had held off
working on it because I didn't want to duplicate efforts; we're short-staffed
enough as it is.
On 2/24/2019 1:02 PM, Manu wrote:
I mean like, my DIP was almost violently rejected,
If it makes you feel any better, Razvan had to endure major rewrites of both the
dip and the implementation.
On 2/24/2019 1:02 PM, Manu wrote:
I mean like, my DIP was almost violently rejected,
I thought it was clear what was needed to be done with it, and I thought you
were going to rewrite it. Was I mistaken?
but in here there's text like this:
"The parameter of the copy constructor is passed
Thank you, Martin!
On 2/10/2019 6:19 AM, Mike Parker wrote:
Victor Porton decided to port an app he developed for a research project from
Ada to D. In the process, he created a bindings and a wrapper for a C library,
librdf. In this post, he shares the approach he took to translating the C API
into the D
On 2/6/2019 11:53 AM, aberba wrote:
I've gotten preoccupied lately with startup stuff and other form distractions,
but I hope to be able to write more D related articles and tutorials on my blog
(aberba.netlify.com) and other mediums this year.
Great! Keep 'em coming!
On 1/31/2019 1:46 PM, Andrei Alexandrescu wrote:
The proposal could actually disallow rvalues that have lvalue syntax, such as
"symbol", "symbol[expr]", "symbol.symbol", "symbol.symbol[expr]", etc. Ugh. Gets
hairy quickly.
That's why it's problematic to have a rule that rvalues can be
301 - 400 of 2363 matches
Mail list logo
