Re: SecureD 3.0 has been released!
On Wednesday, 6 March 2024 at 07:47:04 UTC, Adam Wilson wrote: This version was set in motion by a Cedric Picard, a D community member with Cryptography experience, reaching out and suggesting a number of improvements to the Symmetric and KDF API's. Wow, a Cym13 verified crypto library - excellent news!
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Monday, 11 December 2023 at 19:55:38 UTC, Timon Gehr wrote: There is the following trick. Not ideal since the length cannot be inferred, but this successfully injects alloca into the caller's scope. Wow, what a great hack - I'd have never came up with that!
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: In September 2023, we had one planning session. The major item on the agenda was editions. Other items were a new meeting format, the Bugzilla to GitHub migration, and the future of D. ## Attendees The following people attended the session. * Walter Bright * Ali Çehreli * Martin Kinkelin * Dennis Korpel * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek ## Editions We had agreed in [the September monthly meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywm...@forum.dlang.org) the week before that we need to define what editions will look like before we start deciding which features should go in any given edition. My goal with this session was to establish the first point on the timeline: a deadline for the editions proposal. I also thought it would be a good opportunity for all of us to clarify what editions are (there were some different ideas about that) and discuss aspects of the concept we need to consider. These are excellent progress. I don't wholly agree with the strong commitment on backwards compability DLF decided to make, but with editions it doesn't matter much. The langauge can remain both backwards compatible and develop further at the same time. Here are some points that came out of the discussion. * Editions are essentially feature sets. Each edition can add/remove/deprecate features. * Editions are entirely opt-in and only affect the source you explicitly apply them to, i.e., they are not transitive to dependencies. Makes sense, but on the other hand we will have a lot of questions about templates that are defined in domain of one language edition and instantiated in another. It's going to be onerous to figure out how those cases will work. Regardless, I'm looking forward to this. * Editions will most likely be implemented via an attribute on the module declaration. We haven't discussed any details about that, but for now, just imagine something like `@edition(2024) module foo;`. The syntax isn't critical anyway. That is one small detail that won't have to dominate the discussions. * Features cannot be opted into individually. When you apply an edition to a module, you get the whole thing. Makes sense again. Lifts a lot of maintenance burden for relatively little user inconvenience. OTOH maybe the existing preview/revert flags should stay for the starting version. * The default edition, meaning the code you have now, should compile forever. * We should have a tool that automates as much as possible the migration of modules to new editions Isn't this what the `-transition` switches do? Regardless, mostly agreed. About the question of what would be the default edition. Like others I tend to think that in cases where neither the module nor the compiler invocation has any definitions it should be the latest stable edition. Why? Adding `-edition=2023` (or whatever the flag for the starting edition would be) to the build script of a legacy project is dead simple, and besides needs to be done only once, after which the project will always compile. People don't hate breakage _that_ much. The reverse situation, that we'd have to always either use `-edition=20xx` or explicilty declare the edition in the module header for new code would have the same problems that our `@system` impure defaults for function attributes. At best, it'd annoy people but more likely it'd more or less lead to new code being written in the starting edition because we don't remember or bother with picking the edition.
Re: Warning for anyone who was at DConf.
On Sunday, 3 September 2023 at 07:04:44 UTC, Steven Schveighoffer wrote: Fwiw it’s definitely Covid. I tested positive today. Now trapped in London Heathrow for another week. A bizarre incident, I was on the plane going to Boston and they did a 180 after 30 minutes and booked us the next day. But of course, there is now this. Ugh -Steve Ouch, I'm sorry. Thought I was unlucky when first my continuaton flight got delayed over night and then my luggage got delayed even more. But in fact pretty lucky compared to your story.
Warning for anyone who was at DConf.
Just a while ago I was hit by some sort of a violent ailment. I first noticed it like an hour ago, and I'm shivering as I stand in a well-heated house, despite having had a sauna just a while ago. Temperature already high. I wouldn't rule out having contracted it at DConf, and could well be the Covid. Please watch your health for a few days if you were at DConf or related events.
Re: D Language Foundation July 2023 Monthly Meeting Summary
On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote: __void initialing Booleans__ Dennis wasn't yet finished. The last item he had for us was [a PR he had submitted](https://github.com/dlang/dmd/pull/15362) that marks as `@system` the void initialization of a `bool`, or anything that contains a Boolean, under the system variables preview. The compiler likes to avoid bounds checks if you index with a bool because it knows it can only be zero or one, but when the bool is void initialized, it might be something bigger than that and can corrupt memory. (The PR is attempting [to fix an issue](https://issues.dlang.org/show_bug.cgi?id=20148) brought up in [our Gripes & Wishes campaign](https://github.com/dlang/vision-document/blob/main/gripes-wishes-feedback.md)). He said there were a few different opinions on what should happen here. One is for every void initialization to be `@system`, but that's a bigger breaking change that he doesn't think is going to happen. Would not be recommended anyway. It'd mean any union with `bool` would have to be `@system`. It might be helpful to consider `bool` a type that has unsafe bit patterns. Walter said he would have to think about it, and thanked Dennis for bringing it up. I think `bool` other than 0 or 1 should be allowed, but have implementation defined behaviour: ```D if(*cast(bool) new byte(2)) // implementation defined whether executed // true or false, implementation defined auto x = *cast(bool) new byte(2) && *cast(bool) new byte(2) // true or false, implementation defined auto y = *cast(bool) new byte(2) == *cast(bool) new byte(2) // same as bool z = void auto z = *cast(bool) new byte(2) & *cast(bool) new byte(2) // not implementation defined anymore z = true; ``` This unfortunately means that dmd has to stop assuming bool bit pattern of bool.
Re: The DConf '23 Schedule is Live!
On Tuesday, 6 June 2023 at 13:33:00 UTC, Mike Parker wrote: Thanks again to everyone who submitted talks for DConf '23, and congratulations to those who were accepted. We've got what looks to be another solid lineup this year. Check it out: https://dconf.org/2023/index.html Lol, first a talk about the greatness of DIP1000 and then about the ugliness of it. I'll be happy to hear both! Also interested to hear a talk from Timon. His insights are always so sharp here in the forums, so I'm expecting top-notch observations about tuple design.
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. That DIP sure became a bikeshed at the last review. Good effort from you and Aya to revise and submit it regardless. Note though, the links to the community review currently point to ProtoObject DIP review.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote: The language shouldn't support by default making a storage allocator pure. It's doing its job, saying you can't do this because you're changing state. So you have to fake it by doing a dirty cast in there somewhere. The reason why D supports system code is so you can do dirty things when you have to. It's the same with `const`. D does not support logical const, because logical const is not const. It's not enforceable. That's a feature. If you want logical const, you have to do something dirty to get it, and that's appropriate. No, these are different. `pure` only says the compiler is allowed to cache the result of a function and reuse it for similar calls. You are allowed to do debug logging, or return different results with subsequent calls (by casting an impure function to `pure`), as long as you accept that this results in unspecified behaviour. This means marking a custom allocator `pure` is okay (the [pure factory function](https://dlang.org/spec/function.html#pure-factory-functions) rule forbids the compiler from caching the memory address of the returned result). On the other hand, mutating anything through a `const` reference is not only unspecific behafiour, it is un*defined* behaviour. The compiler may simply assume you don't do this, so if you do, anything may happen. Any D program using `const` as "logical" is excommunicated by the spec. With `pure` hacks, there's more than one thing that may happen, but the options are still limited. With `const` hacks, they are not. The former are dirty hacks but legal, the latter are totally illegal. It they are intended to be the same, the spec needs changes.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote:
Walter also said that whether void initialization should be
allowed in pure code is a different question. Void initializing
an int and returning it isn't pure, is it? So maybe we should
disallow void initializations in pure code. He thinks that's a
reasonable proposition.
I disagree: it makes sense as is. Consider:
```D
@safe pure int fun()
{ int result = void;
return result;
}
@safe void gun()
{ int a = fun(), b = fun();
[a, b].each!writeln;
}
```
What are values of `a` and `b`? They are unspecified. Since `fun`
is pure, the compiler might cache the unspecified value of `a =
fun()` to `b`, but so what? `b` is also unspecified, so it's
expected it could happen to always be same as `a`.
`pure` can and should be able to return unspecified values, as
long as they're unspecified the same way for the same argument
set. About what would be unspecified in different way, and thus
impure, this is an example:
```D
int global;
@safe int impureFun()
{ int local = void;
if (local < global) return global;
else return local;
}
```
This also returns an unspecified value (unless `global ==
int.max`) but it's unspecified in different way depending on
global state (never less than `global` at time of call) so the
compiler rightfully rejects it if you try to mark it `pure`.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote: The monthly meeting for March took place on March 3rd, 2023, at 14:30 UTC, and lasted about an hour and fifteen minutes. The following people attended: As before, a great deal of interesting stuff here. Also useful: with these we aren't left guessing what the Foundation is thinking. We have a much better idea about what kind of ranting could be of value.
Re: Beta 2.103.0
On Thursday, 2 March 2023 at 15:56:35 UTC, ryuukk_ wrote:
```D
@safe ref int wrongIdentity(ref int x) {
return x; // ERROR! Cannot return a ref, please use "return
ref"
}
@safe ref int identity(return ref int x) {
return x; // fine
}
```
a keyword to return a value
``return 5;``
and a keyword to tell that a reference is returnable
``return ref int x``
that's dumb, why?
Late answer, but it happens because DIP25 is now the default.
`ref` without `return` means that the return value cannot refer
to the parameter in question. You can alternatively fix this by
turning function attribute inference on, by omitting `int` from
the function header.
Why DIP25 is needed? Consider this:
```D
int* pointer1;
int* pointer2;
@safe ref int incrementAndCopy(ref int x)
{ return *new int(x++);
}
@safe unittest
{ int local = 0;
pointer1 =
pointer2 = (local);
}
```
The compiler must prevent the first assignment to `pointer`,
because otherwise it would end up pointing to an expired stack
variable. On the other hand, we don't want to disallow harmless
usage of `ref` like that of the `incrementAndCopy` call in the
second assignment. To achieve that, the compiler needs to
distinguish between `ref` variables that may be referenced to by
the return value, and those that cannot. Plain `ref` means it can
not, `return ref` means it can.
Re: 2023: Focusing on stability, GitHub Sponsors, and Frozen DIPs
On Monday, 20 February 2023 at 12:38:56 UTC, Mike Parker wrote: I'm excited because some of the ideas and goals I and others have had for D, the community, and the ecosystem, are starting to take shape. I'm eagerly anticipating the announcements I'll be able to make as the year progresses. Sounds big! Hopefully includes Phobos v2. As a result of a discussion that took place during our January meeting (summary coming this week!), Walter and Átila have decided to shift gears a bit. For the next year, they want to emphasize stability and robustness. This sure is in line with what many have been suggesting. In the meantime, as I have mentioned before, I'm eliminating the Final Review round from the process we have now, and I'm willing to run more than one review at a time. If you have submitted a DIP to the PR queue, I'll be in touch soon to see if you're ready to move forward. Excellent. I intend to publish the January and February meeting summaries by the end of this week. As I mentioned before, I botched my recording of the January meeting (the audio output wasn't recorded, only my microphone was). Given the black hole that is my memory, I had to enlist the help of some of the attendees to gather up enough info for the summary. It won't be at the level of detail you're used to, but it's the best I can do. I'm sorry. Good try anyway.
Re: D Language Foundation Monthly Meeting Summary for November 2022
On Thursday, 12 January 2023 at 11:47:26 UTC, Mike Parker wrote: ### Petar One of the things Petar wants to do toward that end involves the Nix package manager. He's been using it for the past few years. There are already packages for the three D compilers, but they only target the latest stable releases. He would like to create Nix package expressions for "as old as practical" versions of the compilers. It seems we have a common goal. I'm happy to give Petar modification rights to https://github.com/dukc/oldDDerivations (the one that's linked from DMD download page) if he wants. Also if he wants to convert that to also include old LDC and GDC versions, permission granted! (Sent this privately to him last weekend but since I received no reply I assume I have wrong Email address.)
Re: Memory Safer in a Systems Programming Language Part 3
Thanks for Mike, he has done pretty much work in editing each of my posts and keeping everything in order. He's not employed as English teacher for nothing!
Re: Breaking news: std.uni changes!
On Tuesday, 3 January 2023 at 04:13:53 UTC, Richard (Rikki) Andrew Cattermole wrote: On 03/01/2023 10:24 AM, Dukc wrote: Other things coming to mind: Bidirectional grapheme iteration, Word break and line break algorithms, lazy normalisation. Indeed, lots of improvement potential. I've done word break, "lazy" normalization (so can stop at any point), and lazy case insensitive comparison with normalization. Can't wait to see them in master! But: Bidirectional grapheme iteration makes my eye twitch lol. I did write a reverse grapheme iterator for Symmetry. It isn't fit for Phobos as-is since it only accepts UTF-8 strings (not other ranges) and is modeled after the Phobos grapheme walker, not the 15.0 standard. But I could ask for permission to give it to you if it'd help.
Re: Breaking news: std.uni changes!
(Sorry for the late answer) On Wednesday, 28 December 2022 at 00:10:36 UTC, Richard (Rikki) Andrew Cattermole wrote: On 28/12/2022 12:13 AM, Dukc wrote: This is a big service for us at Symmetry. Getting Unicode support up to date was needed, we would have had to switch libraries at some point or update it ourselves. But now, nothing to do except perhaps dealing with a bit of breakage. Thank you! I had no idea that this was becoming an issue for you guys. It wasn't in any of the meeting notes and I haven't seen it brought up anywhere. So if there is anything more like this, please talk about it! Yes, I should have done that. I see it's not quite Unicode 15 though. `graphemeStride` does not take Emoji sequences and prepend characters into account. I'm going to contribute a bit now since it's holiday, and this is a good task for me. PR coming soon unless I run into issues! Yeah, there will be tons of small stuff currently missed out due to such a big jump and of course ping me @rikkimax, when you have something to review. Loads of other work available such as culling all the version specific information out of the docs :) Other things coming to mind: Bidirectional grapheme iteration, Word break and line break algorithms, lazy normalisation. Indeed, lots of improvement potential.
Re: Breaking news: std.uni changes!
On Saturday, 24 December 2022 at 21:26:40 UTC, Richard (Rikki) Andrew Cattermole wrote: Hello one and all on this merry of all days! Today unfortunately I bring all but joy. For std.uni has had a bout of work! - Unicode tables have been updated to 15 from 6.2 (and with that the generator is now in Phobos!). - Unicode categories C aka Other have been brought in line with TR44 specification. E.g. ``unicode.C``. This is a big service for us at Symmetry. Getting Unicode support up to date was needed, we would have had to switch libraries at some point or update it ourselves. But now, nothing to do except perhaps dealing with a bit of breakage. Thank you! I see it's not quite Unicode 15 though. `graphemeStride` does not take Emoji sequences and prepend characters into account. I'm going to contribute a bit now since it's holiday, and this is a good task for me. PR coming soon unless I run into issues!
Re: D Language Foundation Meeting September 2022 Monthly Meeting Summary
On Monday, 17 October 2022 at 14:10:49 UTC, Mike Parker wrote: Finally, I noted that I had spoken to Weka's Eyal Lotem at DConf. He said their biggest remaining sticking point is what happens after a move, which is what originally prompted [one of their employees to write DIP1014](https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1014.md), which introduced `opPostMove` and was accepted. It was never implemented and now never will be, thanks to [the approval of copy constructors in DIP1018](https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md) intended to replace post blits. Huh? First off, DIP1018 replaces postblits, not postmoves. DIP1040, if accepted, will replace postmoves, but it's currently post community 1, not accepted. Second, the readme file at dips directory says DIP1014 is implemented in dmd 2.088.1. Something is wrong here. Regardless, thanks for keeping us up to date.
Re: DIP 1043---Shortened Method Syntax---Accepted
On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: DIP 1043, "Shortened Method Syntax", has been accepted. Excellent! The fact that the feature was already implemented behind a preview switch carried weight with Atila. He noted that, if not for that, he wasn't sure where he would stand on adding the feature, but he could see no reason to reject it now. If there is no reason to reject an already-implemented feature, there's no reason to to reject it as non-implemented either. If it feels like it's too much work to implement an otherwise good DIP, it should be accepted on the condition that someone does it, not rejected IMO. Even if the maintainers don't have time to implement something themselves, it still lowers the bar a lot for someone else to do it when there is a promise to accept any sound implementation. Walter accepted with a suggested (not a required) enhancement: It could be even shorter. For functions with no arguments, the () could be omitted, because the => token will still make it unambiguous. As DIP author, Max decided against this. He said it's not a bad idea, but it's then "inconsistent with other the other syntaxes". If there is a demand for this, it would be easy to add later, but he felt it's better to keep things simple for now by going with the current implementation as is. Good reasoning from Max.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: ### Bastiaan SARC has marked a major milestone in that their 500KLOC Extended Pascal codebase has been completely transcompiled to D (if you aren't aware of this project, you might enjoy Bastiaan's talks from DConf 2017, [Extending Pegged to Parse Another Programming Language](https://youtu.be/NoAJziYZ4qs), and DConf 2019, [Transcompilation into D](https://youtu.be/HvunD0ZJqiA)). Congratulations! ### Mathias Mathias had a few things to bring up. The first was [Issue 23164](https://issues.dlang.org/show_bug.cgi?id=23164), which he encountered when preparing his DConf talk. In short, it looks like dmd is moving structs that have copy constructors. Isn't this exactly what [`opPostMove`](https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1014.md) is for?
Re: D Community Conversations: Walter Bright on the Origins of D Part 1
On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: I'll plan to do one of these every other month, so I'll be reaching out to people around the D community as time goes on. This was great, looking forward to more of these. I've thought that you could well write a blog series about D history. This is pretty much it, except that it's a video series, not a post series. Plus you're also giving a talk about a similar subject at DConf.
Re: The D Programming Language Vision Document
On Sunday, 3 July 2022 at 20:16:35 UTC, Ola Fosheim Grøstad wrote: On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote: It is required for string equivalent comparisons (which is what you should be doing in a LOT more cases! Anything user provided when compared should be normalized first. Well, I think it is reasonable for a protocol to require that the input is NFC, and just check it and reject it or call out to an external library to convert it into NFC. Anyway, UTF-8 is the only format that isn't affected by network byte order… So if you support more than UTF-8 then you have to support UTF-8, UTF16-LE, UTF16-BE, UTF-32LE, UTF-32BE… It is pretty easy to convert those to native endian and back with functions in `std.bitmanip`. I recently did so to have a program to recognise files in all of those five. Also the Phobos functions are of high quality. They work extremely well with the range API (other than having to live with autodecoding), they are well documented and they are comprehensive enough for almost any task. I don't recall having ever considered another library for handling Unicode. And I think there is still pretty much value in handling UTF-16 strings because that's what many other languages use. With the current vision, Phobos V2 won't handle UTF16 in place. We'll have to convert it to UTF8 before manipulation, which is probably not optimal. And if the string functions have to deal with two formats anyway, also supporting UTF32 on top of them probably does not make much difference. That said, I don't feel strongly about this because if we kick UTF16 and UTF32 functions out of Phobos, they still are presumably available in Undead.
Re: The D Programming Language Vision Document
On Monday, 4 July 2022 at 08:34:14 UTC, Mike Parker wrote: [snip] I think that's a reasonable policy. The last thing any of us want is to stifle debate or censor opinions, but we feel that it's reasonable to ask people to participate in debates and express their opinions without upsetting others. So we're going to do our best to find a middle ground. Thanks for the explaination. I agree with all of this. I think we should get into habit to start a new thread for branching discussions with much lower bar than we currently do. Myself included.
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. Thanks, I like to read these summaries - keep 'em coming! This one had so much news that it was almost a D blog post.
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Saturday, 25 June 2022 at 02:03:01 UTC, zjh wrote: On Wednesday, 22 June 2022 at 07:15:34 UTC, zjh wrote: On Tuesday, 21 June 2022 at 15:05:46 UTC, Mike Parker wrote: Good article! [chinese version](https://fqbqrr.blog.csdn.net/article/details/125409915) Wow, thanks!
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Thursday, 23 June 2022 at 14:08:15 UTC, Steven Schveighoffer
wrote:
On 6/23/22 8:01 AM, Dukc wrote:
On Thursday, 23 June 2022 at 00:37:24 UTC, Steven
Schveighoffer wrote:
You mean like a system function which removes the scope-ness
of an array? Let me introduce you to my other thread:
https://forum.dlang.org/thread/t7qd45$1lrb$1...@digitalmars.com
You are allowed to remove `scope` from an argument in unsafe
code. It's only if you escape that argument when you trigger
undefined behaviour. Just like you can cast away `const`, if
you don't actually mutate the cast variable.
And what do you think a custom struct that circumvents the
scopeness is going to do with that parameter?
To be clear, I think we're talking about something like:
```d
struct ScopeArray(T)
{
T[] arr;
@system void opAssign(scope T[] param)
{
arr = param; // escaping scope
}
}
```
-Steve
By `return scope`. I'm not sure if it'd work with that `opAssign`
example since we don't actually return the `this` pointer. I need
to recheck what `return scope` means with `void` return type,
before I write the next article - There is or at least was some
rule regarding that situation.
But in any case you could accomplish the same with
```D
@safe ScopeArray!T(T)(return scope T[] param)
{ return ScopeArray!T(param);
}
```
. Note that in this case you are not even trying to store `scope`
variables as elements to an array, so we don't need `@trusted`.
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Thursday, 23 June 2022 at 00:37:24 UTC, Steven Schveighoffer wrote: You mean like a system function which removes the scope-ness of an array? Let me introduce you to my other thread: https://forum.dlang.org/thread/t7qd45$1lrb$1...@digitalmars.com -Steve You are allowed to remove `scope` from an argument in unsafe code. It's only if you escape that argument when you trigger undefined behaviour. Just like you can cast away `const`, if you don't actually mutate the cast variable.
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven Schveighoffer wrote: On 6/21/22 11:05 AM, Mike Parker wrote: The part about `scope` being shallow. This is a problem. Is there any plan to address this other than "just use `@system`"? -Steve I think a custom `struct` containing a GC:d slice of `scope` arrays could be done. The struct itself needs `@system` code of course but could be `@safe` from outwards perspective, unless there's some issue I haven't thought of. A relatively quick-and-dirty solution would be to use a static array for this, if you know some upper size the array can't exceed. Kinda cheap but probably better than `@system`.
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Wednesday, 22 June 2022 at 21:07:50 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven
Schveighoffer wrote:
The part about `scope` being shallow. This is a problem.
One thing that will be confusing to most users is that it
appears to be using "taint" rather than proper flow analysis on
the pointed-to-object?
```d
int* test(int arg1, int arg2) {
int* p = null;
p =
p = new int(5);
return p; // complains about p being scope
}
```
I'd personally prefer if variable `scope` auto-inference worked
only in the declaration, not later assignments. I guess the
intention is to break less existing code.
Your solution would break even less, but it'd mean the language
rules depend on flow analysis.
Because the rules are now "official", probably best to leave them
as is to avoid confusion.
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Tuesday, 21 June 2022 at 15:05:46 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2022/06/21/dip1000-memory-safety-in-a-modern-system-programming-language-pt-1/ Now on 26. place at Hacker News.
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Tuesday, 21 June 2022 at 22:55:56 UTC, StarCanopy wrote: On Tuesday, 21 June 2022 at 15:05:46 UTC, Mike Parker wrote: [...] ```d int[5] stackData = [-1, -2, -3, -4, -5]; // Lifetime of stackData2 ends // before limitedRef, so this is // disallowed. limitedRef = stackData[]; ``` In the above example, `stackData2` seems to be a typo. Thanks, you're right. Missed that when editing.
Re: Q & A with Razvan Nitu and Dennis Korpel
On Wednesday, 25 May 2022 at 14:43:04 UTC, Mike Parker wrote: I've started a new series on our YouTube channel that I'm calling 'D Community Q & A Sessions'. These are short sessions focused on specific topics. For the inaugural episode, Razvan and Dennis joined me to talk about their roles as the foundation's Pull Request and Issue managers. I did go a little off topic at the end, though, when I asked what they're most looking forward to about DConf '22. https://youtu.be/nvo7wzjVDQc Wow, by the maturity Dennis reflects in the forums/GH I was surprised he is this young!
Re: DIP 1035, "@system Variables", Accepted; DIP 1037, "Add Unary Operator ...", Abandoned
On Wednesday, 13 April 2022 at 07:32:26 UTC, Mike Parker wrote: Walter and Atila have informed me that they have approved DIP 1035, "@system Variables", on the grounds that it identifies a loophole in the `@safe` checks and provides a reasonable solution. Walter said it's a good DIP. Yes. Despite my slight opposition to the DIP in the final review I can't say I'm disappointed. The DIP is still such a piece of art and the feature sounds nice to use, only a bit redundant (which is why I opposed it). Redundancy is not a showstopper after all.
Re: Our New Pull-Request and Issue Manager
On Thursday, 24 February 2022 at 13:05:33 UTC, Mike Parker wrote: 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. So it's many who applied? Glad to hear. Everyone, please congratulate Dennis Korpel on his new job! Good choice indeed! Thanks again to Symmetry for sponsoring this position and helping us to fill it. Seconded!
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. Same. And my personal opinion is, even in general people should not be afraid to use old-fashioned language if they feel like it. It keeps the language colourful. (Unless the old-fashioned language usage means using a deprecated programming language feature. Don't do that :D.)
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 15:43:39 UTC, Ola Fosheim Grøstad wrote: 3. *The politics of language improvements*: I don't think this should be a library type. I think this feature is too important for that. To me this smells of let's move the syntax to a library to avoid any discussion about breaking changes. Design considerations should not become political, we need to get rid of politics and focus on principled strategies that makes the whole eco system attractive to more developers (the ones we don't have). This is a disrespectful comment. You're implying that your opinion is rational and apolitical, disagreeing with it is irrational politics. It is true that no decisions are fully politics-free, but please don't pretend that you are above all others here in that regard.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Wednesday, 2 February 2022 at 22:58:39 UTC, Mike Parker wrote: No, that wasn’t the reason for the delay. Delays in the DIP process always come down to someone waiting for a response from someone else. Everyone involved has multiple priorities, so when the next move comes down to any one person, it will happen when that person is ready to make it happen. In this case, Walter took much longer than usual to get to his initial review. I’ve set a 30-day window for this, but this time he went over. The email discussions with Paul happened over a relatively short period. Then there was a long delay while we waited for Paul to get the changes made. I was busy enough that I put all DIPs out of mind for a while, so I wasn’t pinging him asking for an update. An honest explaination. And this is not a fault with Paul. This happens with nearly every DIP. All of the DIPs that have begun the process and are currently in the queue are stalled waiting for the authors to tell me they’re ready to move to the next round. I ping them periodically, and eventually they’ll be ready. Not Pauls fault nor yours. Were all more or less busy and/or lazy. In any case, if there’s no news on a DIP, it’s almost always because someone is waiting on someone else. If I’m not the reason someone is waiting, then the only update I would ever be able to give is “we’re waiting”. Which would tell that it's not forgotten. You're technically right, what would we do with the information that a DIP is not (or is) forgotten? Perhaps ping sometimes ourselves but that's it. But I think it still might have a bit morale value to do that "we're waiting" update if a formal assesment misses that 30-day window you mentioned, for instance. May be just my taste, though.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote: I want to reiterate that the above is only a summary. Paul and Walter exchanged multiple emails in discussion of these issues, with both proposing ideas to solve them. Paul does an excellent job describing his rationale for only allowing the attribute on structs in the [section I noted above](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1038.md#design-goals-and-possible-alternatives). So this explains why the DIP lingered so long in formal assessment. I think the reason for the delay is good in itself, but it would have been better to update us a bit more on why the assessment is taking so long. From the outside it seemed it's likely forgotten. Anyway, kudos for finally getting all settled!
Re: On the D Blog: A Gas Dynamics Toolkit in D
On Wednesday, 2 February 2022 at 08:14:32 UTC, Mike Parker wrote: The University of Queensland's Centre for Hypersonics has [a gas dynamics toolkit](https://gdtk.uqcloud.net/) that, since 1994, has evolved from C, to C++, and now to D. Peter Jacobs, Rowan Gallon, and Kyle Damm wrote a little about it for the D Blog. The blog: https://dlang.org/blog/2022/02/02/a-gas-dynamics-toolkit-in-d/ Reddit: https://www.reddit.com/r/programming/comments/sij99d/they_wrote_a_gas_dynamics_toolkit_in_d/ This reminds me about SARC. They use D for hydrodynamics software because (among other reasons) it's approachable enough for naval engineers. Now it's revealed that D is used for aerodynamic software because it's approachable enough for aeronautical engineers. Might it have anything to do with that D is designed by one?
Re: On the D Blog: Using the GCC Static Analyzer on the D Programming Language
On Friday, 14 January 2022 at 13:37:11 UTC, Mike Parker wrote: The Blog: https://dlang.org/blog/2022/01/14/using-the-gcc-static-analyzer-on-the-d-programming-language/ Reddit: https://www.reddit.com/r/programming/comments/s3sh9p/using_the_gcc_static_analyzer_on_the_d/ Wow, it looks like the analyzer is easy to use! If bloated in it's error messages.
Re: DMD now incorporates a disassembler
On Friday, 7 January 2022 at 21:41:55 UTC, Walter Bright wrote:
Compile with -vasm to see it! Enjoy!
For the file test.d:
int demo(int x)
{
return x * x;
}
Compiling with:
dmd test.d -c -vasm
prints:
_D4test4demoFiZi:
: 89 F8 mov EAX,EDI
0002: 0F AF C0imulEAX,EAX
0005: C3 ret
https://github.com/dlang/dmd/pull/13447
Wow, very useful! This feature surely lowers the bar to check the
disassembly when optimising. Thanks!
I'm slightly disappointed it does not output the asm inlined to D
code but that's just my daydreaming with no practical reasons to
back it up.
Re: He Wrote a High-Frequency Trading Platform in D
On Saturday, 11 December 2021 at 13:58:02 UTC, Mike Parker wrote: Georges Toutoungis shared his D user experience on the D blog. He went from being excited, to dismissive, to using D to implement an HFT and never looking back. The blog: https://dlang.org/blog/2021/12/11/i-wrote-a-high-frequency-trading-platform-in-d/ Reddit: https://www.reddit.com/r/programming/comments/re075b/he_wrote_a_highfrequency_trading_platform_in_d/ He chose to eschew Phobos, which means he lost quite a bit of the power of D, even in a low latency environment. And he still found D to be a clear improvement over not only C, but C++. That's remarkable IMO.
Re: GDC has just landed v2.098.0-beta.1 into GCC
On Tuesday, 30 November 2021 at 19:37:34 UTC, Iain Buclaw wrote: Hi, The latest version of the D language has [now landed](https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5fee5ec362f7a243f459e6378fd49dfc89dc9fb5) in GCC. As the D front-end for GDC is now itself written in D, in order to build GDC, you will need a working GDC compiler (GCC version 9.1 or later). Wow, congratulations! I quess it finally makes it easier for you too, since you don't have to backport dmd features to C++ anymore.
Re: D Language Foundation Quarterly Meeting, October 2021
On Friday, 5 November 2021 at 11:57:40 UTC, Mike Parker wrote: * The biggest languages have a story. (Java: write once run anywhere, the language of the internet; Rust: memory safety without a GC; Go: goroutines). What is D's story? It's not one big thing, but a lot of little things, and that's not a strong story. I wonder if the underlying theme, that separates us from the rest, is "low or high-level, just as home"? At least when it comes to the stance on GC, that seems to be the hot potato on HN, that applies. Rust advertises working well without the GC. Go advertises working well with the GC. We lobby for working with or without based on situation.
Re: On the Blog: DLang News for September/October 2021
On Friday, 29 October 2021 at 15:03:46 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2021/10/29/dlang-news-september-october-2021-d-2-098-0-openbsd-saoc-dconf-online-swag/ What Razvan mentioned about old PRs is similar to my experience. I have pinged or reviewed a few old PRs and surprisingly often that wakes the PR up. It's a very powerful way to contribute. Starting a forum discussion about some specific ambiguity also works fairly well, assuming you provide good examples and constructively ask questions instead of just ranting. And having a PR manager has been a great boon IMO, both when Nicholas was the manager, and now.
Re: OpenBSD LDC package
On Thursday, 21 October 2021 at 01:59:11 UTC, Brian wrote: Hello D Community -- I'm happy to announce that I have posted a preliminary LDC package for review to OpenBSD: https://marc.info/?l=openbsd-ports=163477542025020=2 With the already shipping GDC and DMD packages, all 3 D compilers are now easily available to OpenBSD users. ~Brian Not regarding LDC, but perhaps you want to publish the DMD port at [our download page](https://dlang.org/download.html) with a nice Puffy image?
Re: DConf Online 2021 T-Shirts
On Wednesday, 20 October 2021 at 11:50:00 UTC, Mike Parker wrote: "Entry" would imply a downward trajectory! Our thing is launching.
Re: DConf Online 2021 T-Shirts
On Wednesday, 20 October 2021 at 09:55:32 UTC, Mike Parker wrote: I'll be giving out only one of each color as prizes during DConf Online (other prizes may include DMan shirts, Amazon eGift cards, D Rocket swag, BEERCONF! shirts, etc.). If you want show one off in the DConf Online edition of Beerconf, then order one ASAP! Where does the name "D rocket logo" come from? It looks like it should be "D atmospheric entry logo"!
Re: Surprise - New Post on the GtkD Coding Blog
On Wednesday, 8 September 2021 at 19:35:21 UTC, Adam D Ruppe wrote: The short version is the wayland devs were hyperfocused on one use case and missed the big picture. This led them to wrongly believe that the majority of X is completely useless legacy bloat, so instead of patching up the one use case, they threw it all out. [snip the bit longer version] I thought that the Wayland architecture is in some way fundamentally better than X architecture, the same way D templates are fundamentally better than imitating them with a macro preprocessor, C or otherwise. But I think you said that it was not about anything that required a redesign from ground up. Like, redesigning the whole Phobos because `Algebraic` sucks instead of adding `SumType` would be our analogy of what Wayland devs did. I have to study differences in their approach more before I decide which I personally prefer.
Re: DIP 1039--Static Arrays with Inferred Length--Withdrawn
On Tuesday, 7 September 2021 at 15:06:48 UTC, Mike Parker wrote: It's been accepted with a request for changes. Walter and Paul are working out the details. Congratulations Paul!
Re: DIP 1039--Static Arrays with Inferred Length--Withdrawn
On Saturday, 4 September 2021 at 07:09:15 UTC, Mike Parker wrote: [snip] Regarding DIPs, any news on status of DIP 1038? It has been on formal assesment over three months now.
Re: Surprise - New Post on the GtkD Coding Blog
On Friday, 3 September 2021 at 18:52:13 UTC, Adam D Ruppe wrote: (i loathe and despise wayland but ill try not to rant) Have you written more about this on your blog? I have read more than one piece that wishes good riddance of X in favour of Wayland, I'd like to read something about the "but" side.
Re: The SAOC 2021 application deadline has passed
On Thursday, 19 August 2021 at 06:59:39 UTC, Mike Parker wrote: Thanks to everyone who submitted an application to the Symmetry Autumn of Code 2021. The SAOC judges will review the applications over the next few days. I'll inform each applicant of their status on August 25th, and will publish a blog post describing the accepted projects shortly thereafter. Can't wait to hear who and what has been chosen!
Re: D News Roundup on the Blog: SAoC, DConf Online, Compiler Releases
On Friday, 18 June 2021 at 13:06:28 UTC, Mike Parker wrote: I've posted a collective announcement of recent big happenings in D Land with all the relevant links. The SAoC 2021 and DConf Online 2021 pages are live with the information you need to submit proposals. Looking forward to see what comes around! The blog: https://dlang.org/blog/2021/06/18/d-news-roundup-saoc-2021-dconf-online-2021-new-compiler-releases/ A lot of content on D blog lately. Good job.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 28 May 2021 at 14:56:08 UTC, Mike Parker wrote: For example, major long-term goals are memory safety (e.g., specific bugs, fully enabling DIP 1000 support) and Phobos v2. Phobos v2 is an official plan? That was news for me! Any chance to get a glimpse of what's planned for it?
Re: BeerConf May 2021
On Saturday, 29 May 2021 at 19:39:35 UTC, Ethan wrote: On Saturday, 29 May 2021 at 14:05:12 UTC, Iain Buclaw wrote: Beerconf is inviting you to a meeting. BEERCONF When I saw "last reply 22 hours ago by Ethan" in the thread title I guessed what you said without looking!
Re: LWDR (Light Weight D Runtime) for Microcontrollers v0.2.3
On Sunday, 30 May 2021 at 14:28:25 UTC, Dylan Graham wrote: Hi, all! This is LWDR (Light Weight D Runtime) It is a ground-up implementation of a D runtime targeting the ARM Cortex-M microcontrollers and other microcontroller platforms with RTOSes (Real Time Operating Systems). Sounds very useful! However, first thing first: What's the license? DUB package says it's FOSS. Great, but what kind of FOSS? It makes a big difference whether it's GNU or BSD, for instance. It doesn't, and possibly may not, support all D features in order to make it viable for the constrained environments. For example, all memory allocation is manually done via `new` and `delete` - no GC. Regarding `new` - is there a good way to iterate though chunks allocated with `new`? One could call an unmodified piece of D code that normally uses the GC, and then manually free all it's allocations. It works by providing a series of barebones API hooks (alloc, dealloc, assert, etc) (defined in `rtoslink.d`), which you must implement and/or point to your RTOS implementation. Quickly looking, the implementation looks very portable, save for exceptions. with `rtoslink.d`, this will probably enable a lot of stuff on any platform without DRuntime. Not just microcontrollers. If I'm right, you just did a BIG service for D on bare-metal. It is beta, so expect bugs. And open source, so the bugs can be fixed as discovered :-). Thanks for the warning anyway.
Re: Destroy All Memory Corruption
On Thursday, 22 April 2021 at 16:15:14 UTC, Ali Çehreli wrote: I failed after spending 35 minutes for that. I ended up creating at least two accounts (even though I already had a Skype account, which sounded to be sufficient). Many special codes sent to my phone and email. The whole thing is badly designed and felt buggy. In the end, contrary to how the download started for "my platform" (Linux Mint) it said at some point that MS Teams was not available for my platform. (There is an MS Teams program on my system which starts fine but thinks I am not signed in. (?)) So I decided to use it in the browser, which turned out not working with Firefox. Luckily I had Chrome and it worked. If you want the desktop application, you might want to try the Nix package: https://search.nixos.org/packages?channel=20.09=teams=0=50=relevance=teams . At least on Nixos and XFCE desktop it works. But setting up the Microsoft account definitely was not my favorite experience either. It asks some strange questions feeling like the app was only for those already in business with Microsoft.
Re: On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
On Thursday, 4 March 2021 at 13:54:48 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ "Some examples: attempting to index an associative array can trigger an attempt to allocate a RangeError if the key is not present; a failed assert will result in allocation of an AssertError; calling any function not annotated with @nogc means GC operations are always possible in the call stack. These and any such operations should be avoided in the destructors of GC-managed objects." I don't understand this part. If an assert was failing, the program is going to terminate anyway, so InvalidMemoryOperationError is no problem. Well, it might obfuscate the underlying error if there is no stack trace, but banning `assert`ing in anything that could be called by a destructor sounds too drastic to me. Even the lowest level system code tends to contain asserts in D, at least in my codebase. If asserting is banned, destructors can do faily much nothing. I'd think it's much more practical to redefine the assert failure handler if InvalidMemoryOperationError due to a failed assert is a problem.
Re: DIP 1034--Add a Bottom Type (reboot)--Formal Assessment Begins
On Wednesday, 3 February 2021 at 09:20:57 UTC, Mike Parker wrote: After a bit of delay, DIP 1034, "Add a Bottom Type (reboot)", is now in the hands of Walter and Atila for the Formal Assessment. Good luck Dennis!
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
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.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 13 January 2021 at 15:31:33 UTC, Nick Treleaven wrote: On Wednesday, 13 January 2021 at 14:48:07 UTC, Atila Neves wrote: Even if they did, what editor are they using that they can't jump back to where they were? Geany. You can set a marker but probably the editor should automatically add to location history before the go to start of file key binding is executed. 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... The screen jumps back to the cursor. Then I scan the screen to see the cursor. It is much easier to spot when I keep it moving with the arrows.
Re: Symmetry Investments and the D Language Foundation are Hiring
On Thursday, 14 January 2021 at 13:24:55 UTC, Atila Neves wrote: https://forum.dlang.org/post/wdsgkozpnhegqkcwe...@forum.dlang.org On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg wrote: BTW, is timestamps vs SHA-1 hashing really the most pressing issue with Dub? Not really, no. You just made a new announcement theard with that reply. Intentional?
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Friday, 8 January 2021 at 12:43:51 UTC, Luhrel wrote: On Friday, 8 January 2021 at 11:49:30 UTC, Dukc wrote: On Thursday, 7 January 2021 at 15:58:24 UTC, Luhrel wrote: [...] It does not compile because length of `s` is not known at compile time. It SHOULD compile if `s` was either a static array or a manifest constant, but currently it does not - what a lucky bug! I still think it deserves a mention -it's standard practice to put the "breaking changes" section even if there are none. In this case it seems a breaking change by the spec, but not by the implementation. Currently, isn't `$` only allowed inside the square brackets ? https://dlang.org/spec/arrays.html#array-length I don't think this bug is valid Yes, and it is inside square brackets - just not as the top-level expression. But no-one claimed it has to be top-level.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Friday, 8 January 2021 at 11:49:30 UTC, Dukc wrote: It SHOULD compile if `s` was either a static array or a manifest constant, but currently it does not - what a lucky bug! Bugzilla: https://issues.dlang.org/show_bug.cgi?id=16213
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Thursday, 7 January 2021 at 15:58:24 UTC, Luhrel wrote:
```
int staticArrFunc(int[6] a)
{
return a[0];
}
void main()
{
int[] s = [1, 2, 3, 4, 5, 6];
int[] y = s[0 .. staticArrFunc(cast(int[$]) [1,2,3])];
// Error: CTFE internal error: trying to access
uninitialized var
}
```
Do you have a currently working example, that would potentially
be broken by my DIP ?
It does not compile because length of `s` is not known at compile
time. It SHOULD compile if `s` was either a static array or a
manifest constant, but currently it does not - what a lucky bug!
I still think it deserves a mention -it's standard practice to
put the "breaking changes" section even if there are none. In
this case it seems a breaking change by the spec, but not by the
implementation.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Thursday, 7 January 2021 at 13:03:54 UTC, Luhrel wrote: I don't get it. 1. `y` should be a int[]. True - see my correction at the feedback theard. 2. if staticArrFunc returns a size_t, then the problem can be simplified as: ``` staticArrFunc(cast(int[$])[1,2,3]); // no need to cast : staticArrFunc([1,2,3]); // already works like that (if staticArrFunc takes a int[3]) ``` If your DIP is implemented, what you say is true. But the point is that right now it means a different thing - a cast to static array of the length of `something` (in the full example), not to length of `[1,2,3]`. The point is that your DIP will silently change the behaviour of code like this. I do agree that this is such a rare enough occurence that we might be best off just accepting it. But it needs to be mentioned in the DIP.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 18:41:31 UTC, Nick Treleaven
wrote:
On Wednesday, 6 January 2021 at 18:33:54 UTC, Dukc wrote:
Why? `arr` is static so the compiler should be able to figure
that no overflow will ever happen.
Because:
1. concatenation with a static array is not defined (use
`arr[]`).
Oh okay.
2. slices do not implicitly convert to a static array.
They do if the length is known at compile time, but `~` does not
for some reason propagate the length. This works though:
```
int[4] bar(int[2] arr)
{ return arr.conc([3, 4]);
}
T[i+j] conc(T, size_t i, size_t j)(T[i] a, T[j] b)
{ typeof(return) result;
result[0 .. i] = a[];
result[i .. $] = b[];
return result;
}
```
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 18:22:32 UTC, Nick Treleaven
wrote:
Type inference for parameters with a default argument could be
made to work.
auto fun(auto a = [1,2,3].staticArray) {return a;}
Okay that was a bad example. But see Luhrels answer to Jacob.
```
int[$] bar(int[2] arr) // Error: not allowed in
functions declarations
{
return arr ~ [3, 4];
}
```
causes an error if the return type is specified as int[4].
Why? `arr` is static so the compiler should be able to figure
that no overflow will ever happen.
```
int[] x = something;
int y = something[0 .. staticArrFunc(cast(int[$])[1,2,3])];
```
Excellent point, but it isn't just casts, anywhere you use a
type (template instantiation) that is within an indexing
expression will have this problem.
Yeah, this is just the simplest example that came to mind.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 17:59:57 UTC, Jacob Carlborg wrote: There's `staticArray` to solve this issue [1]. It does a slightly different thing. staticArray works with types of literals and values, while the proposed way works with type of the declaration. Now you have to either infer the whole type (`auto`) or not infer anything at all. This proposal would let one to infer the length of a static array without inferring it's type. For example, `short[$] arr = [1,2,3]` isn't easily representable with `staticArray`, as `is(typeof([1,2,3].staticArray) == int[3])`. Whether the issues are different enough to justify a new language feature is another question though.
Re: DConf Online 2020...
Did you remember the schelude publication? It was supposed to happen yesterday.
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:
DIP 1030, "Named Arguments", has been accepted.
Good. It has some weaknesses that Rikki's DIP would have avoided
but it's also simpler. Good work, Walter!
"Named arguments breaks this very important pattern:
auto wrapper(alias origFun)(Parameters!origFun args)
{
// special sauce
return origFun(args);
}"
I'm not worried about this one, as AFAIK this does not really
break, it just needs changes to work with the new feature.
Re: DConf Online 2020...
On Tuesday, 8 September 2020 at 09:17:10 UTC, Mike Parker wrote: I was on the verge to cutting the schedule down to one day, but thanks to some last-minute submissions, looks like we'll have enough content now to stretch across two days! Wow! A week ago you told that there was only one relatively late submission besides the keynotes. I thought that if all the other potential submissions missed the deadline, setting another deadline can hardly fare better. But it seems I was wrong. Congratulations for everyone who offered to talk!
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
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.
Good post.
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;}
}
```
Re: A security review of the D library Crypto
On Wednesday, 1 July 2020 at 07:19:11 UTC, Cym13 wrote: Here's what you should know if you are a user: RSA, as implemented in the library, is still very much broken. I do not recommend using it. The confidentiality and integrity of all messages exchanged using this library must be questionned: if you exchanged sensitive information such as passwords using it I recommend to change them since their security is not guaranteed. [snip] Thanks for the article. IMO it was as clear for non-professionals as crypto can be: Even I (non-crypographer) understood what's the problem with padding with only one byte. It also illustrates what's the prolem with cryptography: it's like coding without ability to test. Who could even dream to get that right the first or even the second time? I think there a shortcoming in the "don't roll your own crypto" - advice: One could think it only applies to the algorithms, not the implementation. That's what I did when I first heard it. If one needs to use cryptography, would redundancy help? I mean, encode and decode the message with say three different algorithms from different libraries, so that the attacker would need to find a weakness in all of them?
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Monday, 22 June 2020 at 12:07:26 UTC, 9il wrote: On Monday, 22 June 2020 at 12:04:13 UTC, 9il wrote: So the algorithm would look like: 1. Parse hexadecimal big integer 2. Parse exponent 3. Cast big integer to `Fp` with a specific number of meaningful bits (its already implemented) 4. Add exponent to `Fp`'s exponent, and cast the result to a hardware floating point type. My bad, the hexadecimal parsing is already implemented for big integers! http://mir-algorithm.libmir.org/mir_bignum_low_level_view.html#.BigUIntView.fromHexStringImpl So only a bit left to go. Great! So, each part of the algorithm above is implemented. Maybe we need to rework fromHexStringImpl to make it return a boolean value. Good idea. It should pay back when one wants to parse a big amount of strings that are likely to contain a lot of non-integers.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Sunday, 21 June 2020 at 15:24:14 UTC, 9il wrote: Hey everyone, So excited to finally announce we can correctly parse floating-point numbers according to IEEE round half-to-even (bankers) rule like in C/C++, Rust, and others. Finally a worthy alternative to Vladimir Panteleevs parser [1]. A few months back I went looking for a `nothrow` parser that can handle errors reliably, and I was surprised that I could find only one that was better than my simple custom-made one. Can mir_parse handle other bases than decimal? [1]https://github.com/CyberShadow/ae/blob/master/utils/text/parsefp.d
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 If this is what you say, it could be used for object-oriented programing with types that are not designed as objects. Not only that, in principle the design should work even at a bare-metal platform as I understand it. I know that practical corner cases would prevent doing the latter without extra work, but impressive nonetheless.
Re: DIP1028 - Rationale for accepting as is
On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote: The more I think of Atila's and Walter's responses, the more they are starting to make sense. [snip] In fact this former antipattern means that it'd make sense to have an inverse of `@trusted` attribute, lets say `@suspect`. It would mean that the body of the function is verified just like `@safe`, but calling it is allowed only within `@system` or `@trusted` code.
Re: DIP1028 - Rationale for accepting as is
On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote: Just making `@trusted` wrappers over BindBC-nuklear seemed to me as inresponsible use of the attribute. Meant: blindly making the wrappers, without thinking whether calling the wrapper would always be `@safe`
Re: DIP1028 - Rationale for accepting as is
The more I think of Atila's and Walter's responses, the more they are starting to make sense. When I look my own code that uses the Nuklear GUI library, written in C, it's all `@system`. I have not had the time to make `@trusted` wrappers over the BindBC-nuklear API, so I did what tends to occur to us as the next best thing: resign and make the whole client code `@system`. Just making `@trusted` wrappers over BindBC-nuklear seemed to me as inresponsible use of the attribute. And reading this theard, it would seem like most of you would agree. But when I think it, what I have accomplised from avoiding that antipattern? The only difference is, that if my D code does something `@system`, it'll remain under the radar. So I'm worse off than had I submitted to the antipattern! Now, were I designing a library instead of an application, of course I should not pass such client code as `@safe`, regardless of which of those two ways I choose. But I think the correct way would be to mark the API functions as @system. Then it's be best of both cheap tricks: The compiler will verify my D code from mistakes, but I won't pretend that my code is truly `@safe`.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 18:27:42 UTC, Atila Neves wrote: Sorry, I didn't express myself well. I meant that the user can still mark functions as @system, they just have to do it explicitly. Hm, DPP might be of help here. Becuse I quess you are going to make sure it'll mark everything `@system`?
Re: DIP1028 - Rationale for accepting as is
I can see that happening. A simple example would be:
extern (C) void free(void* p);
...
free(p);
free(p);
The thing is, you are no worse off than now. If free() can be
misused by calling it from system code, it can be misused by
calling it from safe code.
Wrong :-(. The scenario is this:
```
@safe void foo(int* p)
{ import customfreefunction.noannotations;
p.free;
p.free;
}
```
Now, this will not compile, because `free` is `@system`. But if
`free` is in unannotated module, this will compile after the DIP
implementation. Obviously not with the standard library `free`
because it'll be annotated `@system` anyway, but with some custom
`free` function this is an issue.
If the situation in using new features is indeed as dire as you
fear, a better alternative would have been to just reject the
DIP. Then there would be less `@safe` code, but at least you
could trust `@safe` much more, due to the above phenomenon. I do
think there would have been a way to have `@safe` by default even
with the assumptions you made about it's abuse, but the DIP
reviews are over so I don't think it's worth explaining anymore.
But at least you gave the reasonable rationale we wanted. Thank
you.
Re: Hunt Framework 3.0.0 Released, Web Framework for DLang!
On Friday, 1 May 2020 at 10:54:55 UTC, zoujiaqing wrote: [snip] Thanks, but: Some of the files have Apache license, but some have none. I think you should add a license to the whole repository that would cover those files that don't have their own.
Re: DIP Reviews: Discussion vs. Feedback
On Sunday, 26 January 2020 at 09:01:03 UTC, Mike Parker wrote: I'm making a change to the way we solicit feedback during DIP review rounds. The goal is to separate explicit feedback from discussion. Discussion is vital to the process, but it also makes it difficult to find the actionable feedback buried in the 20+ pages that some DIP reviews generate (particularly Walter's). So henceforward, we're going with two threads per review round: one for discussion and one for feedback (critique). It's all laid out in this blog post: https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/ Also on reddit: https://www.reddit.com/r/d_language/comments/eu4fi8/dip_reviews_discussion_vs_feedback/ I think this new policy wants some further pondering. In the feedback theard, if the DIP author replies and the reply indicates that he/she has missed the point of the review, we have a problem. The reviewer cannot answer to the author in the feedback theard, so it has to be done on the discussion theard. With high likelihood, the author will miss the reply on that another theard, and the misunderstanding remains in effect. I think you should let a reviewer to answer to the author in the feedback theard, when the intention is clarify the review. Replying just to disagree with the author, or to comment other reviews still belongs to the discussion thears. That's the minimal fix. However, I suspect there is an alternative arragement, which if as follows: The manager will still create only one feedback theard, where peaple can freely about the DIP and all the reviews given. But to provide a real review, the reviewer will open a new theard and drop a link to to it in the general theard. In the personal review theard, only the reviewer, the author and the DIP manager can talk, and the rules are the same as in the "feedback" theard in the "minimal fix" I described above. To force people to give reviews instead of just bikeshedding in the general theard, there could be a rule that only those who have left a review can participate in the general theard. After the review, the DIP manager will only check the reviews for the review summary. I think this would increase the quality of the reviews, as each reviewer can talk with the author without having the concurrent conversations to drown each other. Thanks for the blog post!
Re: wiki: D on AVR
On Wednesday, 27 November 2019 at 19:30:15 UTC, Ernesto Castellotti wrote: The support to targets that use 16 bits as a pointer size has already been added to LDC (https://github.com/ldc-developers/ldc/pull/2194), so minimal AVR support is present (AVR uses 16 bit pointers). Don't you run into trouble with the fact that the defualt integer size is 32 bits?
Re: Proposal for porting D runtime to WebAssembly
On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote: This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d This proposal is so perfectly balanced between value and implementability that I can find nothing to add or remove. I'm interested, what's your motivation in doing all this? If I understood correctly, your primary motivation to write Spasm was to write better optimized front-end programs than you get with JS frameworks. But wouldn't it be easier to just use Rust since it has already implemented all this?
Re: Proposal for porting D runtime to WebAssembly
On Sunday, 24 November 2019 at 20:42:24 UTC, Sebastiaan Koppe wrote: LLVM errors out saying it can't select tls for wasm. We could modify ldc to not emit TLS instructions under WebAssembly. No need do make that rule WASM-specific. Do this for all programs that have thearding disabled.
Re: rapidxml for D has been ported.
On Tuesday, 8 October 2019 at 09:52:40 UTC, Andrea Fontana wrote: On Tuesday, 8 October 2019 at 08:56:26 UTC, zoujiaqing wrote: [...] So finally we have a working xml parser! Huh? What's wrong with dxml[1]? (Of course it's always good to have alternatives, working or no). 1: http://code.dlang.org/packages/dxml
Re: Spasm - webassembly libary for single page applications
On Tuesday, 6 August 2019 at 22:57:52 UTC, a11e99z wrote: On Tuesday, 6 August 2019 at 20:20:13 UTC, Sebastiaan Koppe wrote: On Tuesday, 6 August 2019 at 19:02:09 UTC, a11e99z wrote: hi. can not compile for Windows LDC ver 1.16.0. Currently ldc 1.16.0 isn't supported. You can downgrade to ldc 1.15.0 spasm 0.1.13: target for configuration "library" is up to date. test_spasm ~master: building configuration "application"... Error: unrecognized file extension lib ?? ldc2 failed with exit code 1. Have you tried the github issues? I remember dukc having the same issue on windows as well. tried. --combined => got error about time.d. could not fix, idk how to fix. Read further down the github issue. You have to hack some included DUB libraries, unless you can come up with a cleaner solution than I did. LDC 1.16.0 is working (it compiles manually) ldc2 1.16.0 will compile the code, but not link it. And if you want to run ldc2 manually, you will want to dry-run dub with verbose and copy the invocation from it. A `--combined` build is too complicated to get working otherwise. Don't mind DUB trying to build an executable. In fact, it has to be. If it builds a "library", it will silently generate some code that's not WASM, or at least can't be used as WASM. The file extension will be incorrect, but you can change it. Sebastiaan just recently opened a LDC2 issue for that.
Re: Phobos is now compiled with -preview=dip1000
On Thursday, 16 May 2019 at 04:29:10 UTC, evilrat wrote: On Thursday, 16 May 2019 at 01:05:53 UTC, H. S. Teoh wrote: ... I hate SFINAE. But.. But D doesn't have it!11 NOOO!!1! Not in the same sense as C++. But if the template constrains rely of is() statements, that is still a kind of explicitly-activated SFINAE. If that's the case here, it's probably the template constraint that's badly designed.
Re: Phobos is now compiled with -preview=dip1000
On Wednesday, 15 May 2019 at 08:26:23 UTC, Walter Bright wrote: This is a good start: http://dconf.org/2017/talks/bright.html Ah, at least something. Thanks.
Re: Phobos is now compiled with -preview=dip1000
On Wednesday, 15 May 2019 at 07:56:48 UTC, Walter Bright 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? Simply add the switch -preview=dip1000 to your builds, and follow where it leads. Bound to cause bad practices without nothing to tell why it works how it works. How do I know when I'm supposed to add `scope`? Or how to react when the compiler complains about escaping references? I have some basic image in my head formed from your DIP paper, but I read somewhere that it's outdated. Could be worth a try even without docs, but in the long run we definitely need some explaining.
Re: Phobos is now compiled with -preview=dip1000
On Wednesday, 15 May 2019 at 07:39:05 UTC, Walter Bright wrote: 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! For me, the forum claims that your posting time is "from the future". Does that mean that is has somehow leaked a draft and this shouldn't show yet? 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?
Re: DConf 2019 Livestream
On Wednesday, 8 May 2019 at 10:13:35 UTC, Ethan wrote: Good news everyone! A Youtube stream will be arriving after the lunch break. Cheers for your patience. Excellent!
Re: DConf 2019 Livestream
On Wednesday, 8 May 2019 at 07:57:40 UTC, Mike Parker wrote: The venue uses WebEx for livestreaming. All the information is available in this PDF: Why does the Webex plugin need access to data from all intenet tabs, and outside the program? Seems suspicious for me.
Re: D 2019 GSoC projects - annoucement
On Monday, 6 May 2019 at 18:15:54 UTC, Seb wrote: Independency of D from the C Standard Library (Stefanos Baziotis) - An effort to decouple D from the C standard library. Does this mean that the GC will be using std.experimental.allocator (as you cannot assume malloc anymore)? Header generation for C/C++ (Eduard Staniloiu) -- Automated C/C++ header generation from D files Definitely has a ton of uses Replace Runtime Hooks with Templates (Dan Printzell) This proposal will work on translating all the array hooks from using the TypeInfo class to templates. So this is the reason why the compiler refused to compile some array operations for me in -betterC. I appreciate that it'll be fixed.
Re: Last Year in D
On Thursday, 24 January 2019 at 13:58:59 UTC, Mike Parker wrote: I said in my annual D Blog retrospective that I wanted to do a similar post focused on D at large. Sebastian Wilzbach sent me a tremendously helpful info dump of all sorts of goings on, most of which I knew nothing about. When I sat down to write the post, it occurred to me that since Adam Ruppe had recently revived 'This Week in D', it would be fun to have him write up a 'Last Year in D'. I asked, he accepted, I sent him Seb's data (thanks Seb!) and the result is now live on the blog. The blog: https://dlang.org/blog/2019/01/24/last-year-in-d/ Reddit: https://www.reddit.com/r/d_language/comments/ajclv0/last_year_in_d_the_d_blog/ Fourth entry this month. Excellent effort!
Re: Blog post: What D got wrong
On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: @safe and pure though... Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed?
