Re: D Language Foundation May 2024 Monthly Meeting Summary
On Wednesday, 28 August 2024 at 12:55:35 UTC, Mike Shah wrote: I do like @live, curious others thoughts? Perhaps it doesn't need to be an attribute though and is instead a compiler flag for an analysis pass on any function (kind of reminds me of frameworks like Soot for Java that you control various analysis passes). Perhaps a conversation for another thread đŸ™‚ The fact that @live is incompatible with existing @safe D code makes it dead on arrival. There are ways to include this kind of analysis without breaking compatibility, but as you say, it has to be a global thing (like DIP 1000), not an attribute that's applied function-by-function.
Re: The New DIP Process
On Wednesday, 28 February 2024 at 03:28:01 UTC, Mike Parker wrote: After discussion in a recent meeting, we're ready now to start accepting DIPs for review. And that means it's time to announce the new process. Very excited to see this. I've already submitted my own DIP idea to get the ball rolling, and am looking forward to seeing what the rest of the community comes up with.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven Schveighoffer wrote: When considering how this should work, I would strongly suggest it be the default to work with the current edition of the language. Nobody wants to always have to attribute their module (or whatever other opt-in mechanism) to use current features. It's going to be a WTF moment for all newcomers to D. This brings us to the problem that no prior libraries have editions marked on them. So I think there needs to be an external mechanism to be able to set the edition for a package or module from the command line, or somehow in a config file. Or you can set the "assumed" edition using a switch (but it should still default to "current"). Worth noting that this is exactly how GCC handles different revisions of the C and C++ standards. [1] It defaults to `-std=gnu18` (C17 with GNU extensions) and `-std=gnu++17` (C++17 with GNU extensions), which are the most recent versions that are fully implemented, but older versions (and previews of newer ones!) can be selected on the command line. D's philosophy of making the safe, recommended choice the default has served it well for features like bounds checking, default initialization, assertions, etc. I hope very much that the same philosophy will be applied to editions. [1] https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C-Dialect-Options.html
Re: DLF September 2023 Monthly Meeting Summary
On Monday, 13 November 2023 at 16:23:05 UTC, Tim wrote: The visitor can already be `extern(D)`. Only member functions overriding those in the base class need to be `extern(C++)`. Other member functions can then use paratemers, which would be incompatible with `extern(C++)`. Wow, it really was that simple all along. Thanks for the tip!
Re: DLF September 2023 Monthly Meeting Summary
On Monday, 13 November 2023 at 10:01:23 UTC, RazvanN wrote: On Sunday, 12 November 2023 at 21:55:31 UTC, Paul Backus wrote: I have no use for overriding AST nodes, but the ability to use `extern(D)` visitors with dmd-as-a-library would be a welcome improvement. I have already brought that up to one of our work group meetings regarding dmd as a library as I have stumbled upon this also. We have a solution for this, I'm going to try to implement it this week. That's great to hear! Thanks for letting me know.
Re: DLF September 2023 Monthly Meeting Summary
On Sunday, 12 November 2023 at 19:50:02 UTC, Mike Parker wrote: https://gist.github.com/mdparker/f28c9ae64f096cd06db6b987318cc581 There was a side discussion about how the `extern(C++)` interface affects dmd-as-a-library. Personally, my number-one complaint with dmd-as-a-library is that I am forced to use `extern(C++)` when creating my own `Visitor` classes. In [`dmdtags`][1], this requirement has made it necessary for me to implement my own C++-compatible [`Span`][2] and [`Appender`][3] types, just to avoid the C++ mangling errors caused by D's built-in `T[]` slices. I have no use for overriding AST nodes, but the ability to use `extern(D)` visitors with dmd-as-a-library would be a welcome improvement. [1]: https://code.dlang.org/packages/dmdtags [2]: https://github.com/pbackus/dmdtags/blob/v1.1.1/src/dmdtags/span.d [3]: https://github.com/pbackus/dmdtags/blob/v1.1.1/src/dmdtags/appender.d
Re: D Language Foundation June 2023 Monthly Meeting Summary
On Thursday, 13 July 2023 at 14:00:49 UTC, Mike Parker wrote: Finally, I told everyone about a conversation I'd had with someone who was planning to submit a proposal to add slices to C. Walter was happy to hear about that, as he had been informally pushing for that for years. He talked about his article on the topic ([C's Biggest Mistake](https://digitalmars.com/articles/C-biggest-mistake.html)) and how C++ had copied that mistake. He says it can be backward compatible in C and analogous to D's slices, it just wouldn't allocate memory for you. Last time this topic came up, I did some research and found a proposal for slices in C23 that was ultimately rejected: https://forum.dlang.org/post/jofetbpwdufuhjznv...@forum.dlang.org If they have not already, the author of this new proposal may wish to familiarize themself with N2660 and its reception by WG 14.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 11 May 2023 at 13:31:58 UTC, Steven Schveighoffer wrote: On 5/10/23 11:22 PM, Paul Backus wrote: In fact, for this particular example, there are actually two enums in the DMD source code that these symbols could be coming from: `enum TargetOS` in `cli.d`, and `enum OS` in `target.d`. So you would have to scroll up and look at the imports to disambiguate. Then you misunderstand the DIP (as did Walter). There is only one enum that can be involved -- typeof(target.os). Oh no, I'm perfectly aware that, from the compiler's perspective, it would be unambiguous--only one of the two enums would actually be in scope. But as a human reader, in order to figure out which one, I'd have to scroll to the top of the file and read through ~25 lines of imports (or rely on tooling, but there are contexts where that isn't available, like a Github code review).
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:
Don't you find this code easier to read and review?
```D
if (target.os == .Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == .linux)
item("linux");
else if (target.os == .OSX)
item("osx");
else if (target.os == .FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == .OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == .Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
Honestly, not really. I've never looked at this part of DMD, and
without context, I'd have no idea where the symbols `Windows`,
`linux`, `FreeBSD`, and so on were coming from. Having it
explicitly spelled out at the usage site--either via qualified
names (`Target.OS.Windows`) or a local alias (`alias TOS =
Target.OS`) makes it trivial to understand what's being referred
to.
In fact, for this particular example, there are actually two
enums in the DMD source code that these symbols could be coming
from: `enum TargetOS` in `cli.d`, and `enum OS` in `target.d`. So
you would have to scroll up and look at the imports to
disambiguate.
Re: A New Era for the D Community
On Sunday, 7 May 2023 at 02:15:02 UTC, monkyyy wrote: On Wednesday, 3 May 2023 at 11:13:34 UTC, Mike Parker wrote: IVY, their organizational development program Your solution to hearing luas dev saying "I dont manage anything" and whatever feedback from your survey, is you got corporate training and now you gun-ho about management? Was I in an extreme minority here? https://monkyyyscience.substack.com/i/93037044/stop-pretending-d-is-a-corporate-language [...] Don't herd cats, just clean out the litter boxes. I basically agree with this--but IMO there are a lot of litter boxes that could use cleaning out, and I'm hopeful that this new approach will help D's leadership do so more effectively. "Management" does not always mean "telling people what to do". Sometimes (often!) it means removing roadblocks and bottlenecks that get in the way of people doing what they already *want* to do.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. IMO this is the correct decision. While a feature like this would be nice to have, it's not of critical importance, so we can afford to have high standards for the quality of the proposal. During the review process, there was some discussion in the community Discord about generalizing this idea, of literals with "holes" that the compiler can fill in, to other types of data beyond just enums. Perhaps it could even be unified with pattern matching--e.g., you could use a pattern as a literal outside of a `switch` or `match` statement, and the compiler would attempt to fill it in based on the context. I can't say with confidence that such a proposal would be accepted (the concerns about top-down vs bottom-up inference still apply), but I personally would be excited to see one.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 28 January 2023 at 13:04:33 UTC, Johan wrote:
Is there a document describing cases where removal of
`@property` does not lead to an error but does lead to a change
in behavior of code?
We are considering a blanket removal of 3000+ instances of
`@property`. The resulting compile errors I can fix (unless
they happen in speculative instantiations, they may be harder
to track down), but I am especially worried about changes in
behavior that do not lead to compile warnings/errors.
Given that the only thing `@property` actually does is change the
result of `typeof` in certain situations, the behavior changes
will probably be things like the following:
```d
static if (typeof(foo.bar) == T) {
// foo has a `T bar` property
} else {
// doesn't have it
}
```
Currently, if `foo` has a `@property T bar();`, this code will
take the first branch. If `@property` is removed, it will take
the second.
Re: GCC 12.2 Released (D v2.100.1)
On Friday, 26 August 2022 at 11:39:53 UTC, Andrey Zherikov wrote: On Friday, 19 August 2022 at 11:36:09 UTC, Iain Buclaw wrote: GCC version 12.2 has been released. Is it possible to add GDC to [github actions](https://github.com/dlang-community/setup-dlang)? There is some discussion here: https://github.com/dlang-community/setup-dlang/issues/35
Re: D Language Foundation June 2022 Monthly Meeting Summary
On Saturday, 25 June 2022 at 01:50:32 UTC, zjh wrote: On Friday, 24 June 2022 at 14:27:17 UTC, Mike Parker wrote: ... I think there should be a more detailed introduction to `'DMD'`. The best introduction is probably Walter Bright's DConf 2016 talk, "Spelunking D Compiler Internals": https://www.youtube.com/watch?v=bNJhtKPugSQ
Re: D Language Foundation June 2022 Monthly Meeting Summary
On Friday, 24 June 2022 at 14:27:17 UTC, Mike Parker wrote: The monthly meeting for June 2022 took place on June 10. Just want to say, thanks for writing up these summaries every month. I'm sure it's not the most exciting work, but the transparency is very much appreciated.
Re: Added xxhash 0.8.1 DUB module (D implementation)
On Sunday, 29 May 2022 at 07:43:20 UTC, Carsten Schlote wrote: Source: https://gitlab.com/carsten.schlote/xxhash3 Dub Code: https://code.dlang.org/packages/xxhash3 [...] Optimized code already outperforms the phobos built-in digest types. See the benchmarks reported by tool at https://gitlab.com/carsten.schlote/hashbench Great work! High-quality implementations of foundational algorithms like these are always a welcome addition to the D ecosystem. :)
Re: D Language Foundation Monthly Meeting for February 2022
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote: **ImportC** Walter told us how he thinks ImportC is going to be a big deal for D. He wants to get us "over the hump" with getting it working properly. He thinks his C extension to allow importing D files in C is working out far better than he expected, and he's considering proposing it to the C committee. The idea that the legendarily-conservative C committee would be willing to consider something like `__import` for standardization strikes me as...extremely optimistic, to say the least.
Re: Our New Pull-Request and Issue Manager
On Thursday, 24 February 2022 at 13:05:33 UTC, Mike Parker wrote: In January, I announced that we were looking to fill the vacant Pull-Request and Issue Manager position sponsored by Symmetry Investments. We received some applications, Symmetry evaluated them, and we agreed on a candidate we believe is perfect for the job. He is a frequent contributor and for the past several months has been working on one of the volunteer strike teams organized by Razvan Nitu, our other PR & Issue Manager. Everyone, please congratulate Dennis Korpel on his new job! Congratulations, Dennis!
Re: Teaching D at a Russian University
On Saturday, 19 February 2022 at 20:26:45 UTC, Elronnd wrote: On Saturday, 19 February 2022 at 17:33:07 UTC, matheus wrote: By the way English isn't my first language but I think there is a small typo: "In D, such nuances are fewer, for header files are not required." I think it's missing the word "example": "In D, such nuances are fewer, for example header files are not required." I think it is fine as is. Yes, this is a perfectly correct use of "for" as a coordinating conjunction. [1] It may come across as a bit formal or old-fashioned, though—in normal speech, you'd usually use "since". [1] https://writing.wisc.edu/handbook/grammarpunct/coordconj/
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Wednesday, 9 February 2022 at 14:30:30 UTC, Guillaume Piolat wrote: On Monday, 7 February 2022 at 19:57:28 UTC, forkit wrote: First, I'm not 'insisting' on anything. I'm just expressing a view. nodiscard is already used by more programmers that D is likely to ever adopt. Indeed, it's these programmers that D is trying to adopt. I'm not sure forcing such people to adapt is necessarily the right approach. I'll have to side with forkit there. In audio software (at the very least) you pay very dearly the price of introducing new _words_, because the existing words embodies existing meaning and practice that users have internalized. In D, there is no existing word for this, so from that perspective both "mustuse" and "nodiscard" are equally valid. In other languages, there are multiple existing words: - C++17: [[nodiscard]] - C (gcc/clang): __attribute__((warn_unused_result)) - Rust: #[must_use] If you are used to C++, then you will find "nodiscard" natural, and "mustuse" will require you to learn a new word. If you are used to Rust, then you will find "mustuse" natural, and "nodiscard" would have required you to learn a new word. And, of course, if you are used to Python or Javascript or one of the many other languages that has no word for this at all, it will make little difference to you either way. C++ is quite popular, but it is not the only popular language, and there are many D programmers who have never used C++ at all, let alone C++17 or later. Therefore, it is a mistake to assume that all or even most D programmers have already internalized "nodiscard", or indeed *any* particular word for this concept.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Monday, 7 February 2022 at 23:40:38 UTC, Walter Bright wrote: On 2/6/2022 9:05 PM, forkit wrote: only to have the compiler complain, that its' actually @mustUse I have to agree. All D keywords and imports and compiler-recognized attributes are lower case, @mustuse should be consistent with that. I guess core.attribute.gnuAbiTag sneaked in behind your back, huh? Anyway, I'm happy to change it if that's your call, although it would have been nice to have caught this before the DIP was officially accepted.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Monday, 7 February 2022 at 05:12:39 UTC, forkit wrote: no amount of replies will change anything ;-) .. people will still 'think' @nodiscard, but have to 'remember' it's actually @mustuse, but oops.. no... it's @mustUse.. I do not expect anything from my feedback ;-) .. I'm just saying..humans are humans.. I've seen similar sentiments expressed many times before, in other contexts. Every time, there are some who insist that the new name will never feel natural to them, and they will never let go of the old name. And every time, history proves them wrong. The fact is, human brains are quite plastic and adaptable. You'll get used to @mustUse, just like I did, and so will everyone else.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Monday, 7 February 2022 at 05:05:27 UTC, forkit wrote: my only concern is the capital U, in @mustUse This seems a little inconsistent with current attributes?? e.g: nogc nothrow inout https://dlang.org/spec/attribute.html also, nodiscard would actually seem more logical, given the above as well. I bet you, people will be thinking nodiscard, but will have to remember to type, @mustuse, only to have the compiler complain, that its' actually @mustUse See my previous replies on this topic: https://forum.dlang.org/post/xgdwevkxqapljcvyj...@forum.dlang.org https://forum.dlang.org/post/yxoinjtarkuotnlnc...@forum.dlang.org
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 20:45:20 UTC, Ola Fosheim Grøstad wrote: On Sunday, 6 February 2022 at 19:14:50 UTC, Paul Backus wrote: Let me rephrase: I do not understand why you feel the need to direct these messages at me, personally. I am sorry if you felt I was addressing you personally. That was not intended, maybe bad phrasing on my part. (I tend to send email when addressing people personally! :-) I am more trying to convey what I see has gone wrong in the "modern C++" design department to "the community" You've been replying directly to my posts. If you intended to direct your messages at "the community" in general, rather than at me specifically, you should have started a new thread. As is, with these messages buried several pages deep in a thread about a different topic, most members of "the community" are unlikely to ever even read them in the first place.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 17:07:46 UTC, Ola Fosheim Grøstad wrote: On Sunday, 6 February 2022 at 16:20:07 UTC, Paul Backus wrote: I did not reply (and do not intend to reply) to any of the numerous other statements you have made in your other replies to this thread, since they are statements about the design of the D language and the DIP process in general, and are not directly relevant to DIP 1038. Well, but it is relevant to the outcome. Let me rephrase: I do not understand why you feel the need to direct these messages at me, personally. I am not a member of the D Language Foundation, and have no particular influence over the DIP process or the design of the D language. If you have ideas or concerns you wish to present to D's leadership, my advice is to either (a) write a DIP, or (b) get in touch with Mike Parker about attending one of the D Language Foundation's monthly meetings (see the bottom of [his latest meeting summary post][1] for details). [1]: https://forum.dlang.org/post/tesktfsmdglmzbhzy...@forum.dlang.org
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 16:01:15 UTC, Ola Fosheim Grøstad wrote: On Sunday, 6 February 2022 at 15:51:46 UTC, Paul Backus wrote: If you're still confused *after* you've read the documentation, feel free to come back and complain to me then. What I stated has nothing to do with documentation. What you stated was, and I quote: It is kinda confusing to call it a user-defined attribute if it is recognized by the compiler. My reply was directed towards that specific statement, and only that statement. I did not reply (and do not intend to reply) to any of the numerous other statements you have made in your other replies to this thread, since they are statements about the design of the D language and the DIP process in general, and are not directly relevant to DIP 1038.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 15:46:47 UTC, Ola Fosheim Grøstad wrote: On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote: On Sunday, 6 February 2022 at 14:44:40 UTC, Ola Fosheim Grøstad wrote: It is kinda confusing to call it a user-defined attribute if it is recognized by the compiler. Compiler-recognized UDAs are an established feature of D. See [`core.attribute`][1] for more examples. I don't need those? So hence I don't care… This feature you are proposing with this DIP is a *very important one* in my view, and I would use it almost everywhere. My point is that "I'm confused because I haven't read the documentation" is a very different complaint from "I'm confused because this feature is inherently confusing." `@mustUse` will be documented in both the language spec ([PR][1]) and the DDoc for core.attribute ([PR][2]). If you're still confused *after* you've read the documentation, feel free to come back and complain to me then. [1]: https://github.com/dlang/dlang.org/pull/3201 [2]: https://github.com/dlang/druntime/pull/3712
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 15:24:17 UTC, Paolo Invernizzi
wrote:
@hold (or @held) ? donwannaopenacanofworms ... my last post
really :-P
Pretend that you are a beginning D programmer, and you come
across one of the following declarations while reading someone
else's code:
@use struct Result
{
// ...
}
@hold struct Result
{
// ..
}
@mustUse struct Result
{
// ...
}
You have never seen any of these attributes before in your life,
and there are no comments explaining what they mean--all you have
to go on is the name. Which name is are you most likely to guess
the correct meaning for: "use", "hold", or "mustUse"?
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 14:44:40 UTC, Ola Fosheim Grøstad wrote: On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote: @mustUse is a user-defined attribute, and the official style guide says that names of UDAs should be camelCased: It is kinda confusing to call it a user-defined attribute if it is recognized by the compiler. Compiler-recognized UDAs are an established feature of D. See [`core.attribute`][1] for more examples. I dislike the camel case as well, and the name is less clear than "nodiscard" in my opinion. I suppose you'll have to take that up with Walter, since he's the one who vetoed "nodiscard". To be honest, though, I can see where he's coming from. When writing DIP 1038, I made a conscious effort to avoid using the term "non-`@nodiscard`", due to the double negative. With a positively-phrased name like `@mustUse`, that problem disappears. [1]: https://druntime.dpldocs.info/core.attribute.html
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 14:32:31 UTC, Paolo Invernizzi
wrote:
While I like a lot and welcome the addition of this attribute
(so thank you!), I humbly ask to reconsider using the full
lowercase alternative instead of camel case.
Let's conform with the other built-in attributes listed into
the specs of the language, avoiding what would be another
special case to remember.
There is precedent for compiler-recognized UDAs using camelCase
in core.attribute.gnuAbiTag [1], as well as the various
LDC-specific attributes [2]. So no matter what I choose here, it
will be inconsistent with something.
If you strongly prefer the lower-case version, you can always
rename it in your own code:
import core.attribute: mustuse = mustUse;
@mustuse struct MyStruct
{
// ...
}
[1]: https://druntime.dpldocs.info/core.attribute.gnuAbiTag.html
[2]:
https://wiki.dlang.org/LDC-specific_language_changes#Attributes
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 13:40:00 UTC, Paolo Invernizzi wrote: On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote: @mustUse is a user-defined attribute, and the official style guide says that names of UDAs should be camelCased: https://dlang.org/dstyle.html#naming_udas ... This matches conventions of the built in attributes like @safe, __@nogc__ ... Presumably this is referring to the part about the first letter being lower-case, since the built-in attributes are quite obviously not camelCased.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N wrote: Guess I'm way too late, I just find it very strange you settled on mixedCase, it's not used for anything else. (nothrow @nogc). I also don't agree with the motivation that @use is hard to search for because @ is an unusual symbol. @mustUse is a user-defined attribute, and the official style guide says that names of UDAs should be camelCased: https://dlang.org/dstyle.html#naming_udas "Hard to search for" in this context means "hard to Google for", not "hard to grep for". Search engines tend to ignore symbols like @.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote: Congratulations to Paul Backus. DIP 1038, "@mustUse" has been accepted after he implemented changes to address concerns from Walter. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md Update for anyone following this: a PR implementing DIP 1038 has been submitted, and is currently awaiting Walter's approval. https://github.com/dlang/dmd/pull/13589
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 14:53:21 UTC, Adam Ruppe wrote: On Sunday, 23 January 2022 at 14:33:26 UTC, Paul Backus wrote: Absolutely-no-breakage-ever is basically the C++ approach, and I have already explained why I think it's a bad idea, though I recognize that reasonable people can disagree on this point. My view is it isn't worth shipping mixed versions at all. I'm against gratuitous breakage; it should actually provide a benefit, and I'm against dead-end breakage; it should provide a migration path. But if there's a path to a benefit, people need to make a choice: take that path, or stop updating. Any middle ground is temporary at best anyway. The main benefit of having multiple versions available in separate namespaces is that it allows them to coexist in the same project, which means that users can migrate their code incrementally from one to the other. In principle you could also accomplish this with a versioned dub package and mangle-prefix [1], but progress on that initiative seems to have stalled out. [1] https://github.com/dlang/dmd/pull/13115
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 12:54:16 UTC, Adam D Ruppe wrote:
I'm not so sure. Isn't the whole point of the versioning thing
so you can use old things that haven't kept up with the latest?
When it was written, sure, they used import std because that's
easy and of course they want the latest stuff.
Then a year later, the latest has moved on and now it is broken.
Unless we ship every std version with the compiler forever,
things will break anyway, because someone will have to go back
and add `undead` as a dependency when std.v{n-1} is removed from
the official distribution.
Absolutely-no-breakage-ever is basically the C++ approach, and I
have already explained why I think it's a bad idea, though I
recognize that reasonable people can disagree on this point.
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 00:07:17 UTC, forkit wrote: On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote: (I think it would also be ideal if the namespace `std` were reserved for the latest stable release... wouldn't this prevent breaking changes from being allowed in a newer version of phobos? by using phobos versioning, you're free of that constraint, and people can opt in or not to a particular version of phobos. of course, then you have the problem of 'std' forever being some version.. from long..long..long ago... is this what they call 'a hard problem' ;-) The way I envision it, `std` would be the "rolling release" namespace that allows breaking changes, and if you wanted stability, you'd have to explicitly depend on `std.vN`. What we currently call `std` would be renamed to `std.v1`.
Re: D Language Quarterly Meeting Summary for January 2021
On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote: ### Andrei Andrei brought up std.v2, but this is where memory fails me. What I do recall is that there was a bit of talk about the std.v2 namespace and how it will live alongside std, and this came up because Robert isn't convinced the planned approach is the right way to go about it. If Andrei or anyone else would like to say more about what was discussed, please post something below. IMO having the `std` and `std.v2` namespaces exist alongside each other *in the official D distribution* would be a mistake, and would make the language significantly less approachable for new users. New users lack the knowledge to make and informed choice between multiple versions of the standard library, and the skills and experience necessary to manage multiple versions in a single project. Therefore, the "out-of-the-box" experience should not present them with such a choice, and should not expect them to manage multiple versions unless they explicitly opt in to doing so. Experienced D users, on the other hand, are much better equipped to deal with the complexities of multiple standard-library versions, and also much more likely to *want* to do so in the first place, since they may have existing projects that depend on older versions. In other words, they have both the means and the motivation to *opt in* to using multiple versions of Phobos. The C++ standard library prioritized backwards compatibility over good UX, and as a result is full of "legacy" traps for unwary beginners, like [`std::auto_ptr`][1] and [`std::lock_guard`][2]. In D's standard library, we have an opportunity to learn from this mistake and do better. We should not let that opportunity go to waste. (I think it would also be ideal if the namespace `std` were reserved for the latest stable release, with `std.v1`, `std.v2`, etc. available on an opt-in basis for users who wish to depend on a specific major version, but this is a much less important point.) [1]: https://en.cppreference.com/w/cpp/memory/auto_ptr [2]: https://en.cppreference.com/w/cpp/thread/lock_guard
Re: All Community Discord channels are now being bridged to Matrix
On Sunday, 16 January 2022 at 00:27:08 UTC, Ali Çehreli wrote: On 1/15/22 15:49, rikki cattermole wrote: > If you don't use Matrix, you can ignore this. I use Emacs. Is that Matrix? :o) Ali Actually it looks like there is a Matrix client for emacs: https://github.com/alphapapa/ement.el
Re: Why I Like D
On Wednesday, 12 January 2022 at 20:48:39 UTC, forkit wrote: Fear of GC is just a catch-all-phrase that serves no real purpose, and provides no real insight into what programmers are thinking. It's all about autonomy and self-government (on the decision of whether to use GC or not, or when to use it, and when not to use it. Programmers want the right of self-government, over their code. Actually, I think *self*-government has very little to do with it. As you correctly observe, D is a great language for programmers who want autonomy--far better than something like Java, Go, or Rust, which impose relatively strict top-down visions of how code ought to be written. In D, you can write C-style procedural code, Java-style object-oriented code, or (with a bit of effort) even ML-style functional code. You can use a GC, or you can avoid it. You can take advantage of built-in memory-safety checking, or you can ignore it. If what programmers care about is autonomy, it seems like D should be the ideal choice. So, why do so many programmers reject D? Because there's something else they care about more than their own autonomy: other programmers' *lack* of autonomy. Or, as it's usually put, "the ecosystem." If you go to crates.io and download a Rust library, you can be almost 100% sure that library will not use GC, because Rust doesn't have a GC. If you go to pkg.go.dev and download a Go library, you can be almost 100% sure that library *will* use GC, because Go *does* have a GC. On the other hand, if you go to code.dlang.org and download a D library...well, who knows? Maybe it'll use the GC, and maybe it won't. The only way to tell is to look at that specific library's documentation (or its source code). Suppose you've already decided that you don't want to use a GC, and you also don't want to write every part of your project from scratch--that is, you would like to depend on existing libraries. Where would you rather search for those libraries: code.dlang.org, or crates.io? Who would you want the authors of those libraries to be: self-governing, autonomous programmers, who are free to use GC as much or as little as they like; or programmers who have chosen to give up that autonomy and limit themselves to *never* using GC? If you're working on a project as a solo developer, autonomy is great. But if you're working as part of a team, you don't want every team member to be fully autonomous--you want some kind of guidance and leadership to make sure everyone is moving in the same direction. In a business setting, that leadership comes from your boss. But in an open-source community, there is no boss. In open source, the only source of leadership and guidance is *the language itself*. If you want to make sure other programmers in your community--your "team"--all agree to not use a GC, the only way you can do that is by choosing a language where GC isn't even an option.
Re: fixedstring: a @safe, @nogc string type
On Wednesday, 12 January 2022 at 19:55:41 UTC, Moth wrote: [snip] Another issue is the way concatenation is implemented. Since FixedStrings have compile-time size, this potentially means every time you concatenate a string in your code you get another instantiation of FixedString. This can lead to a LOT of template bloat if you're not careful, which may quickly outweigh any benefits you may have gained from not using the built-in strings. oh dear, that doesn't sound good. i hadn't considered that at all. i'm not sure how to even begin going about fixing that... One thing you could potentially do is to round the size of the result up to, say, a power of two. That way, instead of instantiating a new template for every individual string length, you only instantiate `FixedString!16`, `FixedString!32`, `FixedString!64`, etc. Of course, doing this will leave you with some wasted memory at runtime. So you will probably want to run some benchmarks to compare performance before and after.
Re: fixedstring: a @safe, @nogc string type
On Tuesday, 11 January 2022 at 17:55:28 UTC, H. S. Teoh wrote:
Generally, I'd advise not conflating your containers with
ranges over your containers: I'd make .opSlice return a
traditional D slice (i.e., const(char)[]) instead of a
FixedString, and just require writing `[]` when you need to
iterate over the string as a range:
FixedString!64 mystr;
foreach (ch; mystr[]) { // <-- iterates over const(char)[]
...
}
This way, no redundant copying of data is done during iteration.
It already does this. In D2, `[]` is handled by a zero-argument
`opIndex` overload, not by `opSlice`. [1] FixedString has such an
overload [2], and it does, in fact, return a slice.
[1] https://dlang.org/spec/operatoroverloading.html#slice
[2]
https://github.com/Moth-Tolias/fixedstring/blob/v1.0.0/source/fixedstring.d#L105
Re: Beta 2.098.0
On Tuesday, 19 October 2021 at 14:48:20 UTC, Tejas wrote: On Tuesday, 19 October 2021 at 13:53:04 UTC, Paul Backus wrote: I this specific case, I agree completely. But there is a broader pattern in D of projects getting "stuck" because a specific individual is unable to continue work on them (e.g., std.experimental.allocator and Andrei), and I think it is worth considering whether we can do anything to make future projects robust against this mode of failure. The obvious solution is more people who get paid to work on D the language/stdlib/rt-env full-time. Where to get money to pay those individuals? Well there's no obvious solution to that (that I know of). We can say community, but, like the vision documents, they will be a bust because one can't _make_ volunteers meet deadlines, code in a particular way, or incorporate all feedback language maintainers think should be acted on. That would help. But also, I think there are probably steps we could take that would make it easier for people other than the original author to pick up existing stalled projects and help move them towards completion. To return to the `std.experimental.allocator` example: there are many people in the community who'd be happy to contribute towards getting it moved out of `experimental`. The problem is, nobody knows what needs to be done, or what the criteria are to consider the project "finished." If the original author(s) had written down, say, a design document and a TODO list, and posted them somewhere publicly visible (maybe the D Wiki?), we would not have this problem.
Re: Beta 2.098.0
On Tuesday, 19 October 2021 at 13:35:16 UTC, Timon Gehr wrote: On 11.10.21 03:08, Paul Backus wrote: Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough? I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise. I this specific case, I agree completely. But there is a broader pattern in D of projects getting "stuck" because a specific individual is unable to continue work on them (e.g., std.experimental.allocator and Andrei), and I think it is worth considering whether we can do anything to make future projects robust against this mode of failure.
Re: DMD Frontend working in WebAssembly
On Friday, 15 October 2021 at 15:19:26 UTC, Imperatorn wrote: Btw, why is dmd a memory hog? Because it doesn't free memory. It just allocates, and relies on the OS to clean up at process exit. See https://www.digitalmars.com/articles/b87.html
Re: New library: argparse, for parsing CLI arguments
On Thursday, 14 October 2021 at 13:37:29 UTC, Andrey Zherikov wrote: Another thing is that I couldn't use `allMembers` without using the module name explicitly, because: `__traits(isModule, __MODULE__)` returns `false` and `__traits(allMembers, __MODULE__)` gives `"mymodule" can't have members, "mymodule" must evaluate to either a module, a struct, an union, a class, an interface or a template instantiation` You can use `__traits(allMembers, mixin(__MODULE__))`.
Re: Beta 2.098.0
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' implementations that haven't been finished. And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him. Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough?
Re: A GUI for DMD, the final version has been release.
On Saturday, 9 October 2021 at 23:02:22 UTC, Murilo wrote: Hi guys, I've just finished the final version of the DMD GUI, there is Linux and a Windows version, click on the link below to download it: https://github.com/MuriloMir/DMD-GUI Nice. Not something I'd use myself, but it might be helpful for beginning programmers getting into D. One thing that might be worth adding is a way to select the working directory, so that you don't have to navigate to the folder with your D code before launching the app.
Re: Bugzilla Reward System
On Friday, 17 September 2021 at 12:39:42 UTC, RazvanN wrote: Given that points are obtained depending on severity, my expectation is that reviewers will pay more attention to it when a PR is submitted. In addition, people that try to score as much points as possible will be interested in making sure that the competition does get the right amount of points. Therefore, I think that the rewarding system will improve the status quo with regards to labeling bugs. My "null hypothesis" expectation is that, absent guidance, reviewers will continue to do what they have always done, which is to pay no attention to the severity at all (except for regressions). I think that this system has the *potential* to improve the status quo, but it will take some effort to actually get reviewers to change their habits. At minimum, we will need to 1. Write down a set of guidelines for how to use the "severity" field on Bugzilla. 2. Copy+paste and/or link to those guidelines in all of our existing instructions for contributors, including: * The `CONTRIBUTING.md` files of the `dmd`, `druntime`, and `phobos` repositories. * Wiki articles like [Get involved][1], [Starting as a Contributor][2], and [Guidelines for maintainers][3]. * The comment that [dlang-bot][4] adds automatically to all new PRs. [1]: https://wiki.dlang.org/Get_involved [2]: https://wiki.dlang.org/Starting_as_a_Contributor [3]: https://wiki.dlang.org/Guidelines_for_maintainers [4]: https://github.com/dlang/dlang-bot
Re: Bugzilla Reward System
On Thursday, 16 September 2021 at 11:56:21 UTC, Mike Parker wrote: https://dlang.org/blog/2021/09/16/bugzilla-reward-system/ From the post: The scoring is designed to reward contributors based on the importance of the issues they fix, rather than the total number fixed. As such, issues are awarded points based on severity: In my experience, the only severity settings most people actually use when filing issues on Bugzilla are "enhancement", "normal", and "regression". And when people do use the other settings, there's no consistency to how they get applied. For example, the first two search results for priority "blocker", issues [22283][] and [22148][], have no indication of what (if anything) they block. Meanwhile, issues [14196][] and [13983][] are both enhancement requests but have their priority set to "major", and issue [22136][] is listed as "critical" even though it is actually a regression! I don't blame anyone who files reports like these. The fact is, there is no official guidance anywhere about what distinguishes a "minor" issue from a "normal" one, or a "normal" issue from a "major" one, so people just guess. But treating the output of this guessing process as though it were meaningful data is probably a mistake. [22283]: https://issues.dlang.org/show_bug.cgi?id=22283 [22148]: https://issues.dlang.org/show_bug.cgi?id=22148 [14196]: https://issues.dlang.org/show_bug.cgi?id=14196 [13983]: https://issues.dlang.org/show_bug.cgi?id=13983 [22136]: https://issues.dlang.org/show_bug.cgi?id=22136
Re: Bison 3.8.1 released with D backend
On Wednesday, 15 September 2021 at 14:48:06 UTC, Tejas wrote: Assuming I'm correct: What does it matter whether the parser is a `.c .cpp .d .pl` or whatever file? I'm really sorry I'm coming off as abrasive/ungrateful. I have no intention to belittle the author or the work she has done. But I'm really curious: What changes if `Bison` outputs it's parser in some language other than the one it originally targeted(perhaps that was C?) Generally speaking, a parser is not a program that you'd run in isolation. When you generate a parser with Bison, it's usually because you want to incorporate that parser into some larger program, like a compiler or a language server. In general, having Bison output its parser in $LANGUAGE makes it easier to incorporate that parser into larger programs written in $LANGUAGE. So giving Bison the ability to output D makes it easier to incorporate Bison-generated parsers into D programs.
Re: SAOC 2021 Projects Summarized
On Monday, 30 August 2021 at 16:12:57 UTC, Adam D Ruppe wrote:
On Monday, 30 August 2021 at 16:03:29 UTC, Guillaume Piolat
wrote:
Hyped by ProtoObject, this is our hope for a nothrow @nogc
.destroy eventually!
This fails today only because of the rt_finalize hook working
through void*. If you cut that out...
---
class Foo {
~this() @nogc nothrow {}
}
void main() @nogc nothrow {
scope auto foo = new Foo();
foo.__xdtor();
}
---
this works today.
I thought the problem with this was that destructors aren't
virtual, so if you write something like this:
---
class Foo {
~this() { }
}
class Bar : Foo {
~this() { }
}
void main() {
Foo foo = new Bar();
foo.__xdtor;
}
---
...then you end up calling Foo's destructor, but not Bar's.
That's why rt_finalize uses TypeInfo to look up the destructor
for the object's runtime type.
Re: dmdtags 1.0.0: an accurate tag generator for D source code
On Friday, 27 August 2021 at 22:45:15 UTC, WebFreak001 wrote: I'm just worried about how the memory usage will grow with this, considering dmd never frees. Maybe I should make it run as external tool instead of a library so the OS cleans up, but for that get a performance penalty especially on Windows. `dmdtags` does not run in the background, so any memory it uses will be freed at process exit, as soon as it has finished writing the tags file. And because it does not do any semantic analysis, only parsing, it does not use much memory while running in the first place. According to `/usr/bin/time`, on my personal machine, using `dmdtags` to generate a tags file for all of Phobos takes slightly less than 1 second and has a peak resident set size of around 100MB.
dmdtags 1.0.0: an accurate tag generator for D source code
`dmdtags` is a tags file generator for D source code that uses the DMD compiler frontend for accurate parsing. This release supports 100%-accurate parsing of arbitrary D code (tested on DMD and Phobos sources), as well as the most commonly-used command line options, `-R`, `-o`, and `-a`. The generated tags file has been tested for compatibility with Vim and is compliant with the [POSIX standard for `ctags`][posix], so any editor with `ctags` support should be able to use it. [posix]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ctags.html ### What? A _tags file_ is a lightweight plain-text index of the symbols in a project. Editors that support tags files, such as Vim and Emacs, can use this index to help with things like project navigation and tab completion. A _tags file generator_ is, as you might expect, a program that reads source code and generates a tags file with entries for the symbols in that code. ### Why? [`universal-ctags`][uctags], the current most-popular and best-maintained tags file generator, claims support for many programming languages, including D. However, its D parser is not well-maintained, and it often excludes large numbers of symbols from its output due to parsing failures. Because `dmdtags` uses the DMD frontend for parsing, its results will always be accurate and up-to-date. For pure D projects, it can be used as a replacement for `universal-ctags`. For mixed-language projects, it can be used together with other tag generators with the `--append` option. [uctags]: https://ctags.io ### Where? * On Github: https://github.com/pbackus/dmdtags * On Dub: https://code.dlang.org/packages/dmdtags
Re: trash-d: Replacement for rm that uses the trash bin
On Wednesday, 25 August 2021 at 13:30:58 UTC, rushsteve1 wrote: On Wednesday, 25 August 2021 at 06:23:37 UTC, Kagamin wrote: You marked all functions inline? If I did then it wasn't on purpose, I was only trying to mark the handful of helper functions as inline. If you know a solution to this, that would be greatly appreciated! When you use an attribute with a colon after it, like you do on [line 232 of trash.d][1]: ```d pragma(inline): ``` Then it applies not just to the next declaration, but to *all* subsequent declarations in the same scope (which in this case is the entire rest of the module). (Source: first paragraph in the ["Attributes" section][2] of the spec.) To avoid this, just remove the colon. To be honest, you could probably remove `pragma(inline)` from the program altogether and not notice a difference. A program like this is almost certainly going to be bottlenecked on IO long before function-call overhead makes a noticeable difference to performance. [1]: https://github.com/rushsteve1/trash-d/blob/00485ca0486e2190fbdfc051fc272c52b8faf014/source/trash.d#L232 [2]: https://dlang.org/spec/attribute.html
Re: trash-d: Replacement for rm that uses the trash bin
On Tuesday, 24 August 2021 at 02:19:58 UTC, rushsteve1 wrote: https://github.com/rushsteve1/trash-d A near drop-in replacement for `rm` that uses the Freedesktop trash bin. Started because an acquaintance `rm -rf`'d his music folder and I thought there had to be a better way. Looks like a nice little utility. Thanks for sharing! One thing I would have liked to see in the README, and had to go digging through the source code for, is a list of supported command-line options. You might consider copy+pasting the output of `trash --help` into the README, to give readers a quick overview of its capabilities.
Re: Destroy All Memory Corruption
On Saturday, 24 April 2021 at 18:16:51 UTC, IGotD- wrote: One remark I found interesting regarding reference counting. "In order to properly run the destructor, you have to run the destructor in an exception handler" Why do you need to run the destructor in an exception handler? I assume it's to ensure that objects are destroyed properly when unwinding the stack. Might be possible to avoid in `nothrow` code.
Re: Beerconf February 2021
On Sunday, 14 February 2021 at 18:22:14 UTC, superbomba wrote: I've tried both Chrome and FireFox (I admit they're all old versions). Interesting that I can visit any stream site like YT, Twitch, Dailymotion and others normally but unfortunately not this Jitsi. The specific browser feature Jitsi uses is called "WebRTC". It's a separate thing from the feature used for video-streaming sites like Youtube and Twitch, so it's not too surprising that one works and the other doesn't.
Re: Article: Why I use the D programming language for scripting
On Monday, 1 February 2021 at 12:11:46 UTC, Petar Kirov [ZombineDev] wrote: On Monday, 1 February 2021 at 11:10:28 UTC, Paul Backus wrote: Unfortunately, you can't pass more than one command-line argument on a #! line. It is possible, using `/usr/bin/env -S command arg1 arg2` , as of coreutils 8.30. I have been using it at work and it's working perfectly. This functionality was already supported by FreeBSD [1] for ~15 years, but the coreutils developers implemented it just ~3 years ago [2]. This is great, thanks! I just checked, and it's available in Debian stable, so most distros should have it by now.
Re: Article: Why I use the D programming language for scripting
On Monday, 1 February 2021 at 09:36:15 UTC, Jacob Carlborg wrote: On Sunday, 31 January 2021 at 20:36:43 UTC, aberba wrote: It's finally out! https://opensource.com/article/21/1/d-scripting FYI, the code will compile faster if you use `dmd -run` instead of `rdmd`. If you have multiple files that need to be compiled you can use `dmd -i -run`. -- /Jacob Carlborg Unfortunately, you can't pass more than one command-line argument on a #! line.
Re: Beerconf January 2021
On Saturday, 30 January 2021 at 16:55:22 UTC, superbomba wrote: On Saturday, 30 January 2021 at 14:21:48 UTC, Iain Buclaw wrote: ...See you all there! Can't participate, both browsers gave me: On FF: 2021-01-30T18:50:28.769Z [modules/browser/BrowserCapabilities.js] This appears to be firefox, ver: 52.0 lib-jitsi-meet.min.js:10:28442 SyntaxError: invalid property id app.bundle.min.js:240:897408 I suspect you need to update your browser. Firefox 52 was released 3 years ago; the current release is Firefox 85.
Re: Please Congratulate My New Assistant
On Tuesday, 26 January 2021 at 16:40:23 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January 2021 at 16:05:03 UTC, Paul Backus wrote: Well, the incorrect behavior is a liability whether we have an issue for it in bugzilla or not. The issue itself is an asset. IFF there is development process that ensure that old issues are being reconsidered for every release. Having a process where >3 year issues are being recorded in a document in a structured fashion probably would be a good idea. Then they could be used for planning. Without that they will most likely never be included in any kind of plan? It is just easier to ignore an "issue" that has been silently accepted for a decade than a recent one. And how are you ever going to implement such a development process if you don't have the old bug reports lying around to begin with? :) I agree that the process you describe would be better than what we currently have, but that does not mean what we currently have is completely worthless.
Re: Please Congratulate My New Assistant
On Tuesday, 26 January 2021 at 13:15:05 UTC, Ola Fosheim Grøstad wrote: On Monday, 25 January 2021 at 21:25:28 UTC, H. S. Teoh wrote: So don't look at the bug count as some kind of liability to rid ourselves of by whatever means possible; rather, look at it as a sign of life and the opportunity to grow. Depends on the nature of the bug, doesn't it? If the bug is related to the compiler rejecting too many programs, then it is ok. If the bug is related to accepting programs it cannot generate correct for, then that is a big issue... Well, the incorrect behavior is a liability whether we have an issue for it in bugzilla or not. The issue itself is an asset.
Re: Please Congratulate My New Assistant
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. Sometimes, reality is demoralizing. That doesn't mean we should hide our heads in the sand and ignore it. It's kinda obvious when you push it to the "limit" that *some* kind of limit has to be put in place. Is it really, though? The purpose of a bug report is to provide useful information to anyone who may want to fix the bug in the future. It follows that as long as (a) the information remains useful and (b) there is a possibility someone might want to fix the bug in the future, the bug report should remain open.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Thursday, 14 January 2021 at 15:30:12 UTC, Dukc wrote: On Thursday, 14 January 2021 at 15:14:36 UTC, Dukc wrote: I use Geany, and I'm no power user, I don't know many key bindings. My way to deal with this is dead stupid: I leave the character cursor where I am and start scrolling. When I want to go back, lArrow rArrow lArrow rArrow... Oh didn't realize you were talking about scrolling to edit, not just to look. In the case of adding an import a though, there should usually be a start of lexical scope close enough to fit in the same screen with the invocation. Except when adding top-level symbols... I reckon I'd just memoize the line number roughly before scrolling. https://www.geany.org/manual/current/#bookmarks TL;DR version: Ctrl-M : create or remove bookmark at current line (mnemonic: M for "mark") Ctrl-, : jump to previous bookmark (mnemonic: on the same key as "<") Ctrl-. : jump to next bookmark (mnemonic: on the same key as ">")
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote: I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves. Seems like the obvious solution is to put the import inside the unittest.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 22:28:04 UTC, jmh530 wrote: On Monday, 11 January 2021 at 21:33:36 UTC, Paul Backus wrote: On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote: Of course, the typical response would be, "well why not use alias s = static array". I would ask what about an @nogc unittest where the author is trying to limit calls to functions that aren't really central to what is being tested. I've used std.array.staticArray for @nogc unit tests. It works fine, and the fact that it has a descriptive name makes it a lot more readable than something like `[1, 2, 3]s`. I know it can be used. My main point was "where the author is trying to limit calls to functions that aren't really central to what is being tested". Yes, and my point is, staticArray is a well-tested standard-library function with an extremely simple implementation, so the odds of it introducing spurious faults into a unit test are essentially zero. So even though I always try to limit calls to unrelated functions in my unit tests, I consider staticArray safe to use.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote: Of course, the typical response would be, "well why not use alias s = static array". I would ask what about an @nogc unittest where the author is trying to limit calls to functions that aren't really central to what is being tested. I've used std.array.staticArray for @nogc unit tests. It works fine, and the fact that it has a descriptive name makes it a lot more readable than something like `[1, 2, 3]s`.
Re: Truly algebraic Variant and Nullable
On Tuesday, 22 December 2020 at 16:54:56 UTC, 9il wrote: On Tuesday, 22 December 2020 at 16:43:30 UTC, ag0aep6g wrote: On Tuesday, 22 December 2020 at 16:32:20 UTC, 9il wrote: "Struct non-static methods marked with the return attribute ensure the returned reference will not outlive the struct instance." The issue isn't that the reference outlives the struct. It's that the reference outlives a tag change of the tagged union. If I am correct Dlang doesn't provide an instrument to validate it, isn't it? What alternative is possible? The solution sumtype uses is to make opAssign @system if the union contains any unsafe types.
Re: Truly algebraic Variant and Nullable
On Tuesday, 22 December 2020 at 03:56:13 UTC, 9il wrote:
On Sunday, 20 December 2020 at 11:00:05 UTC, Tobias Pankrath
wrote:
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:
Truly algebraic Variant and Nullable with an
order-independent list of types.
Thanks for sharing it!
Could you give a (very short) explanation on why sumtype could
not meet your requirements? I am just starting a new D project
and have to choose between sumtype and your solution.
Lets users do comparisons between libraries. Both are very good.
Some mir.algebraic features:
[...]
Mir implements Algebra of (type) sets with reflections
(functions) on it.
It seems like in general, the philosophy of sumtype is to provide
the minimal set of features necessary to cover all possible
use-cases ("mechanism, not policy"), whereas the philosophy of
mir.algebraic is to include a large number of convenience
features out-of-the-box.
The upside of mir.algebraic's approach is that it is easier to
get started with. The downside is that, if you later discover
that the convenience features are not quite what you want, you
will be stuck reimplementing them yourself anyway--and at that
point, the built-in versions will only get in your way.
They also introduce a lot of incidental complexity to the
library. Take a look at the documentation [1] and you'll see a
giant table describing the subtle differences in behavior between
12 (!) distinct accessor functions. By comparison, sumtype has
exactly one accessor function, "match" [2], whose full behavior
is documented in about the same amount of space.
[1] http://mir-core.libmir.org/mir_algebraic.html
[2] https://pbackus.github.io/sumtype/sumtype.match.html
Re: sumtype 1.0.0
On Wednesday, 25 November 2020 at 00:56:39 UTC, sarn wrote: On Wednesday, 25 November 2020 at 00:20:54 UTC, Paul Backus wrote: The exact memory layout and ABI of SumType is deliberately left unspecified. It's an implementation detail that client code isn't supposed to rely on. If you want to pass a SumType's value to a C function, you will first have to extract it using pattern matching. Is that also true of the version being merged into Phobos? Specifically talking about the Phobos version and not the code.dlang.org version, what might change the ABI? Yes. The Phobos version is exactly the same as version 1.0.0 on code.dlang.org, except for some cosmetic changes needed to conform with the Phobos coding style. An example of where someone would care would be D code with a plugin system, or even a shared library with functions that take SumType instances as parameters. The appropriate way to do this is for the D code to pass the SumType to the plugin or shared library as an opaque pointer, and to provide an extern(C) interface that can be used to interact with it. For example, if we want to expose the type `SumType!(int, const(char)*)` to our plugin/shared library as `MySumType`, we might write the following C header file: #include struct MySumType; extern size_t MySumType_sizeof; extern void MySumType_init_int(struct MySumType *, int); extern void MySumType_init_charptr(struct MySumType *, const char *); extern void MySumType_assign_int(struct MySumType*, int); extern void MySumType_assign_charptr(struct MySumType*, const char*); extern int *MySumType_peek_int(struct MySumType *); extern const char *MySumType_peek_charptr(struct MySumType *); Of course, the implementations of these functions would be in D, so they would use pattern matching internally.
Re: sumtype 1.0.0
On Tuesday, 24 November 2020 at 23:02:15 UTC, Dibyendu Majumdar wrote: Thanks - I was suggesting adding a description to the documentation, unless it is already there. Also an ABI specification would be helpful - what happens when a value is passed to a C program. Thanks for the suggestion. The documentation describes SumType as "a tagged union," which I think is enough to get the point across, but I should probably include a link to a definition in case the reader is unfamiliar with that term. The exact memory layout and ABI of SumType is deliberately left unspecified. It's an implementation detail that client code isn't supposed to rely on. If you want to pass a SumType's value to a C function, you will first have to extract it using pattern matching.
Re: sumtype 1.0.0
On Tuesday, 24 November 2020 at 21:52:47 UTC, Dibyendu Majumdar wrote: On Sunday, 15 November 2020 at 20:05:16 UTC, Paul Backus wrote: SumType is a generic discriminated union type for modern D. It is designed to be an improved alternative to `std.variant.Algebraic`. Nice. Is it possible to describe how these types are represented in memory? Anyone who uses unions and wants to use these would want to know whether these types are laid out like unions or not. What is the size of the type - is it equal to the largest member? SumType uses a union internally, so the types all share the same memory. The size of the SumType is equal to the size of the union plus the size of the tag (plus padding, if necessary).
sumtype 1.0.0
SumType is a generic discriminated union type for modern D. It is
designed to
be an improved alternative to `std.variant.Algebraic`.
Features:
- Pattern matching, including:
- Match-by-introspection ("if it compiles, it matches") (★)
- Multiple dispatch (★)
- Support for self-referential types (`This`).
- Works with `pure`, `@safe`, `@nogc`, `nothrow`, and
`immutable` (★)
- Compatible with `-betterC` and `-dip1000` (★)
- Zero runtime overhead compared to hand-written C
- No heap allocation
- Does not rely on runtime type information (`TypeInfo`) (★)
Starred features (★) are those that are missing from `Algebraic`.
With this release, SumType's public API is officially considered
stable. No
breaking API changes will be made from this release forward
without a major
version bump.
Improvements since 0.10.0, the last announced version:
- Copy constructors of SumType members are now called correctly.
- Self-referential SumTypes can now contain self-referential
Algebraics, and
vice versa.
- SumType is now tested on Windows in addition to Linux and Mac
OS X.
Links:
- Documentation: https://pbackus.github.io/sumtype/sumtype.html
- DUB: https://code.dlang.org/packages/sumtype
- Github: https://github.com/pbackus/sumtype
Re: New language based on D
On Friday, 13 November 2020 at 15:22:03 UTC, Dibyendu Majumdar wrote: On Friday, 13 November 2020 at 13:41:50 UTC, Paul Backus wrote: It sounds like maybe your time would be better spent improving the official D documentation to say which features and libraries are compatible with betterC and which are not. Not really. It is a waste of time trying to do that. Why is it a waste of time? If I understand your proposal correctly, you will be doing more or less the same work either way--that is, figuring out which features and libraries still work with certain language features disabled. The only difference is whether you write up your results in a separate document, or incorporate them into the official documentation.
Re: New language based on D
On Friday, 13 November 2020 at 12:25:48 UTC, Dibyendu Majumdar wrote: Fortunately or not - I have limited time - so I won't be making changes to D other than very simple patches to switch off some things. I simply cannot afford to spend time on maintaining a different code base. My main focus will be to create documentation. I can probably do one thing - guarantee that the new language is a proper subset of D and that any code in laser-D is guaranteed to build with dmd, ldc, gdc. It sounds like maybe your time would be better spent improving the official D documentation to say which features and libraries are compatible with betterC and which are not.
Re: sumtype 0.10.0: multiple dispatch
On Tuesday, 27 October 2020 at 16:26:10 UTC, vitamin wrote:
Hello,
Older version of sumtype accept this code:
void main(){
import sumtype;
alias Val = SumType!(bool);
const bool b = true;
Val val = b; //fail in newest version
val = b; //fail in newest version
}
but new version need exact type:
void main(){
import sumtype;
alias Val = SumType!(bool);
bool b = true; //cannot be const
Val val = b;
val = b;
}
is it bug in new version or old version?
It's a bug in the new version. Thanks for reporting. I've opened
an issue on Github for this:
https://github.com/pbackus/sumtype/issues/47
Re: LDC 1.24.0-beta1
On Monday, 19 October 2020 at 13:59:42 UTC, Adam D. Ruppe wrote: On Monday, 19 October 2020 at 13:43:14 UTC, Bastiaan Veelo wrote: I'm not suggesting that this fills the need of newbies, but there is this: https://dlang.org/install.html. Nobody should ever follow those terrible instructions, they leave you so fragile in the event of future updates, takes superuser install access, and just generally scatters crap. Are we looking at the same instructions? The ones I see at that URL don't require superuser access and install everything to a self-contained directory in the user's $HOME. It's pretty much exactly what you recommend, with a bit of extra automation.
sumtype 0.10.0: multiple dispatch
SumType is a generic sum type for modern D. It is designed to be
an improved
alternative to `std.variant.Algebraic`.
Features:
- Pattern matching, including:
- Match-by-introspection ("if it compiles, it matches") (★)
- Multiple dispatch (★)
- Support for self-referential types (`This`).
- Works with `pure`, `@safe`, `@nogc`, `nothrow`, and
`immutable` (★)
- Compatible with `-betterC` and `-dip1000` (★)
- Zero runtime overhead compared to hand-written C
- No heap allocation
- Does not rely on runtime type information (`TypeInfo`) (★)
Starred features (★) are those that are missing from `Algebraic`.
The big new feature in this release is multiple dispatch: you can
pass multiple
SumType arguments to a single `match` call, and it will pass each
of those
SumTypes' values as a separate argument to the selected handler.
If you're used to calling `match` with UFCS, the syntax for
passing multiple
arguments may take some getting used to. I recommend the
following idiom:
bool sameDimensions(Point p1, Point p2)
{
// Set up your handlers first
alias doMatch = match!(
(Point2D _1, Point2D _2) => true,
(Point3D _1, Point3D _2) => true,
(_1, _2) => false
);
// Now make the actual call
return doMatch(p1, p2);
}
Other improvements since 0.9.0, the last announced version:
- SumTypes can be used as keys in associative arrays
- isSumType!T is now true if T implicitly converts to a SumType
- sumtype's license has been changed from MIT to Boost 1.0
- Member types with non-const `opEquals` overloads finally work
correctly
- Various other bug fixes and documentation improvements
Links:
- Documentation: https://pbackus.github.io/sumtype/sumtype.html
- DUB: https://sumtype.dub.pm
- Github: https://github.com/pbackus/sumtype
Re: Beta 2.094.0
On Saturday, 12 September 2020 at 13:40:34 UTC, Per Nordlöw wrote: On Saturday, 12 September 2020 at 13:03:29 UTC, Paul Backus wrote: How many improvements does this warning have to block before we decide its value for the language is net-negative? There's also the option of improving the diagnostic of unreachable code. Is there? Issue 14835 was reported in 2015. If nobody's been able to come up with an improvement in 5 years, what are the odds that this year will be the one that lets us finally crack it? Genuine question, by the way. If it's just an issue of "nobody's had time to work on it," then there may be nothing to worry about.
Re: Beta 2.094.0
On Saturday, 12 September 2020 at 11:43:03 UTC, MoonlightSentinel wrote: Currently looking into enabling it by default but it showed an interesting side effect. The frontend can now conclude that a == b is always true if a and b are instances of an empty struct (without custom opEquals). This caused "unreachable code" warnings for VariantN in Phobos and could probably affect other projects as well. How many improvements does this warning have to block before we decide its value for the language is net-negative? GCC doesn't have it. [1] Clang has it, but only if you specifically ask for it with -Wunreachable-code; it's not part of -Wall or -Wextra. [2] Rust has it, but lets you turn it off with an annotation. [3] Java has it, but it explicitly does *not* take constant-folding into account. [4] The only language I could find that follows D's approach is C# [5], and C#'s generics don't get a separate semantic analysis for each concrete type like D's templates do. [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html [2] https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code [3] https://doc.rust-lang.org/rust-by-example/attribute/unused.html [4] https://docs.oracle.com/javase/specs/jls/se14/html/jls-14.html#jls-14.22 [5] https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0162
Re: D mentionned in the ARTIBA webzine for an article on Silq
On Thursday, 3 September 2020 at 09:24:01 UTC, Jacob Carlborg wrote: On Thursday, 3 September 2020 at 08:40:32 UTC, aberba wrote: The slack I have no ideas how people get in. I know there's a number of members in there too. Unfortunately you need to be invited. Anyone can do it, if you're interested. We just need an email address. May I have an invitation for snarwin@gmail?
Re: Blog Post: What Does Memory Safety Really Mean in D?
On Thursday, 27 August 2020 at 14:10:36 UTC, Dennis wrote: On Thursday, 27 August 2020 at 13:32:44 UTC, Paul Backus wrote: Of course, you could also argue that these are things that shouldn't be allowed in @safe code to begin with--regardless of whether pointers are involved. I did not intend to argue anything with that post, I was just pointing out the limitations of the workaround if it were used today, in case Dukc wasn't aware of them. I think presenting @system variables as "protection" against memory corruption is the wrong way frame the discussion. Is that still in reply to me (or DIP1035)? I don't recall saying something like that and don't want to get the wrong message across. I agree with everything you just wrote. It was really a response to the discussion about DIP 1035 (and Andrei's critique in particular), using your post as an excuse to soapbox; apologies for the confusion.
Re: Blog Post: What Does Memory Safety Really Mean in D?
On Wednesday, 26 August 2020 at 15:34:26 UTC, Dennis wrote:
On Wednesday, 26 August 2020 at 14:29:46 UTC, Dukc wrote:
I think there is a workaround to the variable access being
always safe. Something like this in a dedicated module:
```
struct SystemVar(T, bool safeVal)
{ private T _var;
static if (safeVal) @safe pure nothrow @nogc auto val()
{ return _var;
}
else pure nothrow @nogc auto val(){return _var;}
pure nothrow @nogc ref var(){return _var;}
}
```
This currently does not protect against:
- SystemVar.tupleof[0] (unless you have -preview=dip1000 set)
- __traits(getMember, SystemVar, "_var")
- aliasing (put SystemVar!int in a union with a plain int /
cast SystemVar!int[] from int[])
- void initialization
Of course, you could also argue that these are things that
shouldn't be allowed in @safe code to begin with--regardless of
whether pointers are involved.
I think presenting @system variables as "protection" against
memory corruption is the wrong way frame the discussion. The
problem is that, currently, it is only possible to provide @safe
access to certain kinds of data (discriminated unions,
ref-counted pointers, etc.) by having @trusted code make
assumptions about @safe code that must be manually verified.
There is, technically, nothing wrong with this. The D language
spec does not place any restrictions on what assumptions you are
allowed to make in @trusted code; it merely requires that you do
the legwork to manually verify those assumptions if you want the
compiler's automatic verification of @safe code to give the
correct result.
What @system variables do is allow you to document, in
machine-readable form, a particular kind of assumption ("this
variable is never accessed directly from @safe code"), and have
the compiler check it for you. In other words, they make @trusted
code more *expressive* and *ergonomic*.
Re: Blog Post: What Does Memory Safety Really Mean in D?
On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote: https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html Oops, wrong link. Here's the correct one: https://pbackus.github.io/blog/what-does-memory-safety-really-mean-in-d.html
Blog Post: What Does Memory Safety Really Mean in D?
https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html What exactly do we mean when we talk about "memory safety" in D? Is it the same thing as "undefined behavior"? Is it ever correct to mark and `extern(C)` function as `@trusted`? This post is my attempt to understand, and answer, questions like these. If you think I've gotten anything wrong, please leave a reply--this is definitely an area where I'm still learning.
Re: Article: the feature that makes D my favorite programming language
On Saturday, 25 July 2020 at 18:24:22 UTC, Jesse Phillips wrote: On Saturday, 25 July 2020 at 14:47:01 UTC, aberba wrote: On Saturday, 25 July 2020 at 13:28:34 UTC, Adam D. Ruppe wrote: On Saturday, 25 July 2020 at 11:12:16 UTC, aberba wrote: Oop! Chaining the writeln too could have increased the wow factor. I didn't see that. oh I hate it when people do that though, it just looks off to me at that point. Ha ha. If you're writing idiomatic D code, why not not all in on it? It bugs me too, though I have done it. I think the right answer of why it is odd is because writeln is void. As soon as it is placed on the end the chain is broken and you can't expand on it. This is no different from any other "sink" that consumes a range: someSource .map!foo .filter!bar .splitter(baz) .each!quux; `each` returns void [1], so using it ends the chain. But that's not a problem, because the whole *point* of using `each` is to consume the range. [1] Not exactly, but close enough.
Re: DConf Online 2020 (Formal Announcement)
On Thursday, 23 July 2020 at 14:43:23 UTC, Mike Parker wrote: I've just published the formal announcement of DConf Online 2020 to the blog and shared it on reddit. If you have time, please check the comments in the reddit thread for any questions you can answer and myths you can refute about D! The blog: https://dlang.org/blog/2020/07/23/dconf-online-2020-call-for-submissions/ Reddit: https://www.reddit.com/r/programming/comments/hwgshr/dconf_d_programming_language_conference_online/ Typo: the link to the DConf Online 2020 website actually goes to the DConf 2019 website.
Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 14:56:09 UTC, aberba wrote: Why no one is using your D library So I decided to write a little something special. Its my love letter to D folks. https://aberba.vercel.app/2020/why-no-one-is-using-your-d-library/ Excellent article. As the author of a moderately-popular dub package, I'm convinced that one of the reasons it's succeeded where other similar packages haven't is that I've made high-quality documentation a priority. For anyone interested in learning more about how to write good documentation, I've found the guide at writethedocs.org to be a good resource: https://www.writethedocs.org/guide/
Re: From the D Blog: A Pattern for Head-mutable Structures
On Saturday, 27 June 2020 at 15:06:12 UTC, Avrina wrote: Do you understand what prioritizing is? Fake internet points are being prioritized over ease of access to the community. Another way to frame it is that "respecting the rules of another community (HN) is being prioritized over a minor convenience for the D community." If we would like others to treat the D community with respect, I think it is only fair that we treat their communities with respect as well.
Re: News on the D Blog: SAOC 2020 and More
On Wednesday, 24 June 2020 at 16:15:30 UTC, Andrei Alexandrescu wrote: On 6/23/20 10:31 AM, Meta wrote: By the way I found this helpful: https://chrome.google.com/webstore/detail/smile-always/jgpmhnmjbhgkhpbgelalfpplebgfjmbf?hl=en And for firefox users: https://addons.mozilla.org/en-US/firefox/addon/smart-amazon-smile/
addle 0.1.0 - argument-dependent lookup for UFCS functions
Are you tired of D's sane, straightforward scoping rules? Itching
for a taste of that old-fashioned C++ madness? Well, itch no
more: addle is here to help.
addle is a tiny library that implements C++-style
argument-dependent lookup (ADL) for D, on an opt-in basis. It
lets you extend existing types with UFCS methods, and share those
methods seamlessly with code in other modules--no `import`
required!
Here's a brief example:
import addle;
import std.range;
// Import a type from another module
import mylib: MyStruct;
// Define range primitives for MyStruct
bool empty(MyStruct a) { return false; }
string front(MyStruct a) { return "ok"; }
void popFront(MyStruct a) {}
// MyStruct isn't considered an input range, because
// std.range can't see our UFCS methods.
static assert(isInputRange!MyStruct == false);
// ...but extending it makes those methods visible.
static assert(isInputRange!(Extended!MyStruct));
void main()
{
import std.range: take, only;
import std.algorithm: equal;
MyStruct myStruct;
// Now we can use all of the standard range algorithms
assert(
myStruct.extended
.take(3)
.equal(only("ok", "ok", "ok"))
);
}
Now available on Dub, by "popular demand"!
Links:
- Documentation: https://addle.dpldocs.info/addle.html
- Dub: https://code.dlang.org/packages/addle
- Github: https://github.com/pbackus/addle
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote:
With a few changes, yes (added missing semicolons, changed
IGeometry to Geometry in `measure`, passed the current module
so tardy can find the UFCS functions, added `@safe pure` to the
UFCS functions:
[...]
void main() {
auto r = Rect(3.0, 4.0);
auto c = Circle(5.0);
Geometry.create!__MODULE__(r).measure;
Geometry.create!__MODULE__(c).measure;
}
IMO this can be done more elegantly by separating out the code
that looks up methods in the current module from the code that
does the actual type erasure.
A while ago, I collaborated briefly with Adam Kowalski from the
Dlang discord server on some code to emulate C++-style
argument-dependent lookup in D. Using that code, your example
above would be written:
Geometry.create(r.extended).measure;
Geometry.create(c.extended).measure;
Here's a gist with the code, along with a small example:
https://gist.github.com/pbackus/0a70419eb8bece52f3a08edfe7b6019b
If anyone thinks it's worthwhile, I can toss this up on Dub.
Personally, I've never had much use for it in my own projects.
Re: Interesting work on packing tuple layout
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 the existing tuple implementation would be problematic. Presumably any such change would be made backwards-compatible. So Tuple.opIndex and Tuple.expand would still return elements in the order specified by the user, even if that order is different from the internal storage order.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy Cool stuff! What's the reasoning behind implementing your own vtables instead of using D's built-in object system? Don't want to be stuck inheriting from Object?
Re: Alpine Linux 3.12 Released With D Language Support
On Saturday, 30 May 2020 at 21:48:32 UTC, Johan wrote: Great work. Which compilers (and versions) are available? -Johan Looks like dmd [1], ldc [2], and gdc [3] are all there. [1] https://pkgs.alpinelinux.org/package/edge/community/x86_64/dmd [2] https://pkgs.alpinelinux.org/package/edge/community/x86_64/ldc [3] https://pkgs.alpinelinux.org/package/edge/community/x86_64/gdmd
Re: DIP 1028 "Make @safe the Default" is dead
On Saturday, 30 May 2020 at 16:17:49 UTC, Steven Schveighoffer wrote: +1 this would be perfect. Not sure if this would work either, but both of these are already reserved words: default @safe: -Steve It would probably have to be something more like `default(@safe)`, since `default @safe:` ought to mean the same thing (in principle) as `default: @safe:`.
Re: DIP 1028 "Make @safe the Default" is dead
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote: 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. 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 hope that you and Atila do not take the reception of DIP 1028 as a blow against @safe in general, and that you will continue to look for ways to improve the safety of the D language.
Re: Rationale for accepting DIP 1028 as is
On Thursday, 28 May 2020 at 02:47:01 UTC, Jonathan M Davis wrote: Walter has acknowledged the problem and seems to think that because it's the programmer's responsibility to deal with extern(C) functions correctly (since it's not possible for the compiler to do it), it's up to the programmer to go and fix any existing code that should be marked @system and isn't and that having the compiler incorrectly mark extern(C) declarations as @safe isn't a big problem, because programmers need to be spending the time to check them anyway. He's already created some PRs to try to fix some issues with extern(C) declarations in druntime and explicitly markingthem as @system but doesn't seem to think that it's ultimately a big deal. - Jonathan M Davis I've submitted a PR [1] to fix a whole bunch of these. It's currently blocked on what appear to be irrelevant CI failures (one of which is actually acknowledged as such in the discussion on Walter's PR). No one has given it any attention. Is there something I'm doing wrong? Should I be splitting my PR by file, to make it easier to review? I have a similar PR for Phobos in the works, and it would be nice to have some feedback on this so that one doesn't get ignored too. [1] https://github.com/dlang/druntime/pull/3117
Re: Rationale for accepting DIP 1028 as is
On Wednesday, 27 May 2020 at 05:54:32 UTC, 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 example of currently compiling and correctly working code that will break? Setting aside use of __traits(compiles, ...). I am paraphrasing an earlier post of mine in this thread: https://forum.dlang.org/post/yvcjpcxfyyobqubjr...@forum.dlang.org The breakage is that functions which are currently correctly considered @system will instead be considered @safe. As a result, future changes to @safe code are at risk of introducing memory corruption. Strictly speaking, the breakage does not occur until those future changes are made, so it is more accurate to say that changing un-annotated extern declarations to @safe-by-default will put existing code *at risk* of silent breakage. Given the prevalence of such declarations in existing code (e.g. [1]), I think it is inevitable that this risk will in fact lead to breakage in practice, so I do not consider the distinction particularly important to draw in this context. [1] https://github.com/dlang/druntime/pull/3117
Re: Rationale for accepting DIP 1028 as is
On Tuesday, 26 May 2020 at 22:47:03 UTC, Gregory wrote: If Walter believed greenwashing was actually a problem, then the best solution to prevent it would be to not make @safe by default. If it's not that serious of a problem that he will push through @safe by default, then greenwashing isn't actually a problem and extern(C) should remain @system. I understand your point now, and I agree.
