Re: Is D programming friendly for beginners?
On Monday, 11 March 2024 at 12:30:10 UTC, Doigt wrote: On Monday, 4 March 2024 at 13:37:53 UTC, Fidele wrote: I want to start learning D programming language it looks interesting Depends what you mean by "beginner". If you've never programmed before and D is your first language, then the answer is a definite no. Why definitely not? https://youtu.be/V2YwTIIMEeU?si=j3cQzzN4jsUQrN9C=682 -- Bastiaan.
Re: Using ImportC to augment a big C project with D
On Tuesday, 20 February 2024 at 18:33:42 UTC, Carl Sturtivant
wrote:
2.
The C source calls exit() from C's stdlib, and D needs to
terminate properly.
What do you mean by "need"? You can call
https://dlang.org/phobos/core_stdc_stdlib.html#.exit from D:
```d
import std.stdio;
void main()
{
scope(exit) writeln("Bye");
import core.stdc.stdlib : exit;
exit(0);
}
shared static ~this()
{
writeln(__FUNCTION__);
}
```
Output:
```
onlineapp._sharedStaticDtor_L11_C1
```
So it does run module destructors, but not `scope(exit)`
statements (which probably makes sense).
I would expect `exit()` called from the C source to have similar
results.
--Bastiaan
Re: Fluid 0.6.0 — UI library for D
On Wednesday, 31 January 2024 at 06:38:17 UTC, aberba wrote: On Thursday, 25 January 2024 at 12:33:31 UTC, cookiewitch wrote: Fluid is a library I started developing 3 years ago when I joined the D community, after failing to find a suitable library for my gamedev project. [...] Could you have a small documentation website? Could even be based on something like GitHub pages or readthedocs (https://readthedocs.io). There is this https://fluid.dpldocs.info/v0.6.1/fluid.html and https://fluid.dpldocs.info/v0.6.1/fluid.showcase.html. -- Bastiaan.
Re: Upcoming talk at FOSDEM 2024 - The D Programming Language for Modern Open Source Development
On Monday, 15 January 2024 at 00:49:25 UTC, matheus wrote: On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote: Hi D Community, My talk on how I'm using the D programming language and why I think it is an excellent language choice for open source projects will be featured at FOSDEM 2024 at the start of February 2024 in Brussels, Belgium. Look out for the official talk schedule(in the Main Track) here: https://fosdem.org/2024/schedule/events/ [...] Hi Mike are you sure the link is right, or you're on that list? - I tried "D Programming", your name (And only Surname) but I couldn't find anything. This is the link: https://fosdem.org/2024/schedule/event/fosdem-2024-2092-the-d-programming-language-for-modern-open-source-development/ -- Bastiaan.
Re: Upcoming talk at FOSDEM 2024 - The D Programming Language for Modern Open Source Development
On Monday, 15 January 2024 at 00:49:25 UTC, matheus wrote: On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote: Hi D Community, My talk on how I'm using the D programming language and why I think it is an excellent language choice for open source projects will be featured at FOSDEM 2024 at the start of February 2024 in Brussels, Belgium. [...] Look out for the official talk schedule(in the Main Track) here: https://fosdem.org/2024/schedule/events/ Hi Mike are you sure the link is right, or you're on that list? The main track in that link is still empty. Here is a link for just the main track, also empty: https://fosdem.org/2024/schedule/track/main/ You'd think the main track has been finalized by now (it is only 18 days until the start of the conference) and since all other rooms have plenty of entries already, this list being empty seems like a malfunction to me. -- Bastiaan.
Re: `static` function ... cannot access variable in frame of ...
On Monday, 15 January 2024 at 23:06:00 UTC, Steven Schveighoffer
wrote:
As a workaround, you can alias the outer function in the struct:
```d
struct S
{
alias foo = S_foo;
}
```
This might be less than ideal, but at least it works.
It does! And it's good enough for me. Thanks a lot!
-- Bastiaan.
Re: `static` function ... cannot access variable in frame of ...
On Monday, 15 January 2024 at 18:43:43 UTC, user1234 wrote: The two calls are not equivalent. so what is passed as alias need to be static too. Thanks all. I thought a static member function just isn't able to access the instance of the struct, but as I understand now it is static all the way. What I am looking for is a way to have different structs that have a member function that has the same name in all of them, that is callable without a this pointer, and able to take an alias argument. That is probably asking too much. -- Bastiaan.
`static` function ... cannot access variable in frame of ...
Hey people, I can use some help understanding why the last line
produces a compile error.
```d
import std.stdio;
struct S
{
static void foo(alias len)()
{
writeln(len);
}
}
void S_foo(alias len)()
{
writeln(len);
}
void main()
{
const five = 5;
S_foo!five; // Fine
S.foo!five; // Error
}
```
The error is
```
onlineapp.d(7): Error: `static` function
`onlineapp.main.foo!(5).foo` cannot access variable `five` in
frame of function `D main`
onlineapp.d(19):`five` declared here
onlineapp.d(21): Error: template instance
`onlineapp.main.foo!(5)` error instantiating
```
It seems to me this should just work.
Thanks!
--Bastiaan.
Re: Beta 2.107.0
On Tuesday, 2 January 2024 at 12:49:51 UTC, Iain Buclaw wrote: http://dlang.org/changelog/2.107.0.html **@standalone** is a new attribute that can be used to mark module constructors that run after druntime has been initialized, but do not depend on any other module constructors being run before it, so it will not cause a cyclic dependency error. Nice!! --Bastiaan.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Monday, 11 December 2023 at 19:55:38 UTC, Timon Gehr wrote:
... this successfully injects alloca into the caller's scope.
```d
import core.stdc.stdlib:alloca;
import std.range:ElementType;
import core.lifetime:moveEmplace;
struct VLA(T,alias len){
T[] storage;
this(R)(R initializer,return void[]
storage=alloca(len*T.sizeof)[0..len*T.sizeof]){
this.storage=cast(T[])storage;
foreach(ref element;this.storage){
assert(!initializer.empty);
auto init=initializer.front;
moveEmplace!T(init,element);
initializer.popFront();
}
}
ref T opIndex(size_t i)return{ return storage[i]; }
T[] opSlice()return{ return storage; }
}
auto vla(alias len,R)(R initializer,void[]
storage=alloca(len*ElementType!R.sizeof)[0..len*ElementType!R.sizeof]){
return VLA!(ElementType!R,len)(initializer,storage);
}
void main(){
import std.stdio,std.string,std.conv,std.range;
int x=readln.strip.to!int;
writeln(vla!x(2.repeat(x))[]);
}
```
You guys are great!
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Sunday, 10 December 2023 at 22:59:06 UTC, Nicholas Wilson wrote: Always happy to help if you're interested in looking into using dcompute. Thank you, I'll let you know! Or you could use grep with `--output-ll` as noted by Johan https://github.com/ldc-developers/ldc/issues/4265#issuecomment-1376424944 although this will be with that `workaroundIssue1356` applied. Thanks for highlighting this, as I must have forgotten. I should be able to create a CI job that checks this as part of the release. This will give us the confidence that we need. -- Bastiaan.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Sunday, 10 December 2023 at 18:16:05 UTC, Nick Treleaven wrote: You can call `alloca` as a default argument to a function. The memory will be allocated on the caller's stack before calling the function: https://github.com/ntrel/stuff/blob/master/util.d#L113C1-L131C2 I've just tested and it seems it works as a constructor default argument too. Clever!
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Sunday, 10 December 2023 at 17:11:04 UTC, Siarhei Siamashka wrote: On Sunday, 10 December 2023 at 15:08:05 UTC, Bastiaan Veelo wrote: The compiler can check if `scope` delegates escape a function, but it only does this in `@safe` code --- and our code is long from being `@safe`. So it was a bit of a puzzle to find out which arguments needed to be `scope` and which arguments couldn't be `scope`. This reminded me of https://forum.dlang.org/thread/myiqlzkghnnyykbyk...@forum.dlang.org LDC has a special GC2Stack IR optimization pass, which is a lifesaver in many cases like this. Interesting. Are there some known blocker bugs, which prevent a safe usage of LDC in production? This one: https://github.com/ldc-developers/ldc/issues/4265 Mike has summarized it: LDC unfortunately had an issue that caused stack corruption on 32-bit Windows. They'd hit it in one case and were able to work around it, but he couldn't be sure they wouldn't hit it somewhere else. He wasn't willing to risk unreliable computations. He said that LDC could do the right thing, but his understanding from talking to Martin was that implementing it would have a large time cost. Since Win32 is going to eventually go away, he wasn't very keen on paying that cost. They'd spoken at DConf about the possibility of LDC raising compilation errors when stack corruption could occur so that they could then work around those cases, but he hadn't followed up with Martin about it. -- Bastiaan.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Sunday, 10 December 2023 at 15:31:55 UTC, Richard (Rikki) Andrew Cattermole wrote: It will be interesting to hear how dcompute will fare in your situation, due to it being D code it should be an incremental improvement once you're ready to move to D fully. Yes, dcompute could mean another leap forward. There are so many great things to look forward to. -- Bastiaan.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Wednesday, 6 December 2023 at 16:28:08 UTC, Mike Parker wrote: Bastiaan reported that SARC had been testing their D codebase (transpiled from Pascal---[see Bastiaan's DConf 2019 talk](https://youtu.be/HvunD0ZJqiA)). They'd found the multithreaded performance worse than the Pascal version. He said that execution time increased with more threads and that it didn't matter how many threads you throw at it. It's the latter problem he was focused on at the moment. I have an update on this issue. But first let me clarify how grave this situation is (was!) for us. There are certain tasks that we, and our customers, need to perform that involves a 20 logical core computer to crunch numbers for a week. This is painful, but it also means that a doubling of that time is completely unacceptable, let alone a 20-fold increase. It is the difference between in business and out of business. Aside from the allocation issue, there are several other properties that our array implementation needs to replicate from Extended Pascal: being able to have non-0 starting indices, having value semantics, having array limits that can be compile-time and run-time, and function arguments that must work on arrays of any limits, also for multi-dimensional arrays. So while trying to solve one aspect, care had to be taken not to break any of the other aspects. It turned out that thread contention had more than one causes, which made this an extra frustrating problem because just as we thought to have found the culprit, it did not have the effect that we expected. These were the three major reasons we were seeing large thread contention, in no particular order: 1) Missing `scope` storage class specifiers on `delegate` function arguments. This can be chalked down as a beginner error, but also one that is easy to miss. If you didn't know: without `scope` the compiler cannot be sure that the delegate is not stored in some variable that has a longer lifetime than the stack frame of the (nested) function pointed to by the delegate. Therefore, a dynamic closure is created, which means that the stack is copied to new GC-allocated memory. In the majority of our cases, delegate arguments are simple callbacks that are only stored on the stack, but a select number of delegates in the GUI are stored for longer. The compiler can check if `scope` delegates escape a function, but it only does this in `@safe` code --- and our code is long from being `@safe`. So it was a bit of a puzzle to find out which arguments needed to be `scope` and which arguments couldn't be `scope`. 2) Allocating heap memory in the array implementation, as discussed in the meeting. We followed Walter's advice and now use `alloca`. Not directly, but using string mixin's and static member functions that generate the appropriate code. 3) Stale calls to `GC.addRange` and `GC.removeRange`. These were left over from an experiment where we tried to circumvent the garbage collector. Without knowing these were still in there, we were puzzled because we even saw contention in code that was marked `@nogc`. It makes sense now, because even though `addRange` doesn't allocate, it does need the global GC lock to register the range safely. Because the stack is already scanned by default, these calls were now superfluous and could be removed. So now all cores are finally under full load, which is a magnificent sight! Speed of DMD `release-nobounds` is on par with our Pascal version, if not slightly faster. We are looking forward to being able to safely use LDC, because tests show that it has the potential to at least double the performance. A big sigh of relief from us as we have solved the biggest hurdle (hopefully!) on our way to full adoption of D. -- Bastiaan.
Re: New DUB documentation
On Friday, 24 November 2023 at 11:11:53 UTC, BoQsc wrote: Darker blending indistinct colors (dark red, dark background), way smaller fonts. I see your screenshots, but that is not what it looks like for me in Chrome on Windows. I am seeing black text on white background with red links. Pretty much like the rest of the D web ux. Is there a dark theme you have enabled? The font does look slightly smaller, though. -- Bastiaan.
Re: New DUB documentation
On Wednesday, 22 November 2023 at 21:35:34 UTC, WebFreak001 wrote: the revamped DUB documentation I started a while ago is now deployed on https://dub.pm This is very much appreciated. A job well done! -- Bastiaan.
Re: Returning a reference to be manipulated
On Friday, 14 April 2023 at 00:50:31 UTC, kdevel wrote:
```
ref int foo (ref int i)
{
return i;
}
ref int bar ()
{
int i;
return foo (i);
}
void main ()
{
import std.stdio;
auto i = bar;
i.writeln;
}
```
Up to dmd v2.100.2 I am warned/get an error during compilation:
```
$ dmd returnref2.d
returnref2.d(3): Deprecation: returning `i` escapes a reference
to parameter `i`
returnref2.d(1):perhaps annotate the parameter with
`return`
$ dmd -dip1000 returnref2.d
returnref2.d(3): Error: returning `i` escapes a reference to
parameter `i`
returnref2.d(1):perhaps annotate the parameter with
`return`
```
With later dmd versions (up to including v2.102.2) the code
compiles without complaints. Is this intended?
I think this is intended. Adding `@safe:` on top makes the
complaint come back (in dmd 2.102 it is deprecated, in 2.103 it
is an error).
-- Bastiaan.
Re: Traverse a DList and insert / remove in place?
On Sunday, 19 March 2023 at 13:15:58 UTC, Armando wrote:
I would like to do something like traversing a DList, operating
on the current element, and potentially removing that element
or inserting a new one before/after it - an easy operation if
you code a DList yourself. Maybe I missed something?
This is one way to do that:
```d
import std;
struct MyType
{
int id;
// [...] other stuff
}
void main()
{
auto list = DList!MyType();
// Fill the list.
foreach (i; 0 .. 10)
list.insertBack(MyType(i));
// Traverse the list, conditionally remove one element.
for (auto range = list[]; !range.empty;)
if (range.front.id == 3)
list.popFirstOf(range);
else
range.popFront();
// Traverse the list, conditionally insert one element.
for (auto range = list[]; !range.empty;)
{
if (range.front.id == 6)
list.insertBefore(range, MyType(66));
range.popFront();
}
// Print modified list.
foreach (e; list)
writeln(e);
}
```
Output:
```
MyType(0)
MyType(1)
MyType(2)
MyType(4)
MyType(5)
MyType(66)
MyType(6)
MyType(7)
MyType(8)
MyType(9)
```
https://run.dlang.io/is/kk80FD
-- Bastiaan.
Re: Beta 2.103.0
On Thursday, 2 March 2023 at 16:40:12 UTC, jmh530 wrote: Any reason why it doesn't match the options from DMD? See the [changelog](https://dlang.org/changelog/2.103.0.html#colors): The previous **automatic**, **on**, **off** values are still supported, but undocumented, because they are used in almost no other program like this. For consistency, with other Linux tools especially, we have implemented and switched the defaults to the widely-used **auto**, **never**, **always** values.
Re: toString best practices
On Thursday, 9 February 2023 at 17:49:58 UTC, Paolo Invernizzi
wrote:
```
import std.format, std.range.primitives;
struct Point(T)
{
T x, y;
void toString(W)(ref W writer, scope const ref
FormatSpec!char f) const
if (isOutputRange!(W, char))
{
put(writer, "(");
formatValue(writer, x, f);
put(writer, ", ");
formatValue(writer, y, f);
put(writer, ")");
}
}
void main(){
import std.format : format;
assert( format("%s", Point!int(1,2)) == "(1, 2)");
import std.experimental.logger;
sharedLog.infof("%s", Point!int(1,2));
}
```
Pasting this into https://run.dlang.io/, it just works. That's
for DMD 2.099, so it might be a regression -- or recent feature?
-- Bastiaan.
Re: Safer Linux Kernel Modules Using the D Programming Language
On Thursday, 5 January 2023 at 20:24:07 UTC, Alexandru Militaru wrote: Hi everyone, If you remember the "D for a @safer Linux Kernel“ talk from DConf 2019 [1], then you might want to read our paper [2] on that matter that was just published in IEEE Access Journal. [1] https://youtu.be/weRSwbZtKu0 [2] https://ieeexplore.ieee.org/document/9987502 Kudos to you for staying on the ball on this topic. I enjoyed your talk back then and this article adds credibility to this important application of the language and addresses a wider audience. Well done. Bastiaan.
Re: Beta 2.102.0
On Monday, 2 January 2023 at 12:21:43 UTC, Hipreme wrote: `pragma(lib)` seems to be broken Can you file an issue for this please, if you've not done so yet? https://dlang.org/bugstats.html -- Bastiaan.
Re: D Language Foundation October 2022 Quarterly Meeting Summary
On Wednesday, 2 November 2022 at 18:20:42 UTC, H. S. Teoh wrote: On Wed, Nov 02, 2022 at 06:11:12PM +, M. M. via Digitalmars-d-announce wrote: Thank you to Martin Nowak for all his as release manager. Happy to hear that someone like Ian took over. I'm just curious why Martin stepped down. If he doesn't mind sharing the reason. From what I've heard, Martin started his own business, which takes up all his time. Wishing you success, Martin! -- Bastiaan.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: This summary is quite a bit overdue. Sorry for the delay. Thanks for this, and for keeping all the details. Good work! — Bastiaan.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 11:04:45 UTC, Steven Schveighoffer wrote: On 8/28/22 6:37 AM, Mike Parker wrote: SARC has marked a major milestone in that their 500KLOC Extended Pascal codebase has been completely transcompiled to D This is awesome! I remember that talk, and it was very interesting. Congratulations! -Steve Thank you! The process takes several times longer than anticipated, but we are not giving up :-) Although it is an important milestone, it doesn’t mean we can now all code in D. Almost all commits still happen in Pascal. I have started transpiling every commit separately, to create a commit history in D that overlaps the Pascal history for some period. Next week we plan on using the D versions of our software internally, to expose a larger surface area to testing and scrutiny. This is arguably a bigger milestone. What we all look forward to the most is the last milestone though, where we’ll freeze the Pascal repository and switch from programming in Pascal to programming in D overnight. — Bastiaan.
Re: How do you work with lst files?
On Wednesday, 24 August 2022 at 22:29:51 UTC, Christian Köstlin wrote: I want to ask around how you from the dlang community work with .lst coverage files? No personal experience, but there are half a dozen options on https://code.dlang.org/search?q=Coverage — Bastiaan.
Re: How to escape control characters?
On Thursday, 31 March 2016 at 03:15:49 UTC, cy wrote:
This might be a dumb question. How do I format a string so that
all the newlines print as \n and all the tabs as \t and such?
The easiest is this:
```d
import std.conv;
string str = `Hello "World"
line 2`;
writeln([str].text[2..$-2]); // Hello \"World\"\nline 2
```
I know this is an old post, but I felt this trick needed to be
shared.
This takes advantage of the fact that `std.format` escapes the
characters in an array of strings. So we create an array where
`str` is the only element, and convert that to text. Without the
`[2..$-2]` slicing the output would be `["Hello \"World\"\nline
2"]`.
A slightly more efficient implementation is
```d
string escape(string s)
{
import std.array : appender;
import std.format : FormatSpec, formatValue;
FormatSpec!char f;
auto w = appender!string;
w.reserve(s.length);
formatValue(w, [s], f);
return w[][2 .. $ - 2];
}
```
And the inverse:
```d
string unescape(string s)
{
import std.format : FormatSpec, unformatValue;
FormatSpec!char f;
string str = `["` ~ s ~ `"]`;
return unformatValue!(string[])(str, f)[0];
}
```
Perhaps `escape()` and `unescape()` should be part of
`std.format` so that they can be refactored to use
`std.format.internal.write.formatElement` directly, eliminating
the conversion to array.
-- Bastiaan.
Re: New WIP DUB documentation
On Thursday, 18 August 2022 at 14:00:38 UTC, Martin Tschierschke
wrote:
What about the following idea about **comments for dub.json**:
Allow the key "comment" inside the json file and alter DUB to
remove all "comment" key value pairs at the beginning of
parsing.
So the file is still valid json but comments are possible like
in dub.sdl.
```
{
"comment" : "dub.json can contain comments,too!",
"name": "myproject",
"description": "A little web service of mine.",
"authors": ["Peter Parker", "John Doe"],
"homepage": "http://myproject.example.com;,
"license": "GPL-2.0",
"dependencies": {
"vibe-d": "~>0.9.5"
}
}
```
That's already possible, as unrecognised items are ignored. This
is however not flexible enough, as comments are not so much
wanted for adding explanations but much more for commenting out
specific parts. It does work sometimes: you can for example
disable `preBuildCommands` by editing it to
`preBuildCommandsDISABLED`. I don't think you can comment out a
dependency this way, and you cannot comment out an item from an
array like
```json
{
"preBuildCommands": [
"step one",
#"step two",
"step three"
]
}
```
-- Bastiaan.
Re: New WIP DUB documentation
On Monday, 15 August 2022 at 21:32:23 UTC, WebFreak001 wrote: Hi all, I'm currently working on new revamped DUB documentation, check it out if you want, it currently contains most old documentation plus a big bunch of new documentation: https://docs.webfreak.org/ Thank you for doing this! Not sure if this would be the right place, or if it is addressed already, but I repeatedly find myself looking for the right way to use a local checkout of a package instead of the dub registry, because I keep forgetting. It would be nice to have a section like (assuming I got it right): ## Hacking on a local copy of a package If your project depends on a package in which you have found a problem, or you would like to experiment with changes to it, you can force Dub to use a local copy of the package by following these steps: 1. Fork the git repository 2. Check out a local clone at `/path/to/the_package` 3. Let Dub know about it: `dub add-local /path/to/the_package` 4. Make Dub ignore any configured release tag, so you'll see the effect of current changes: `dub add-override the_package * /path/to/the_package` Now you can go ahead and play. Once your PR has been merged and released, or you want to revert to upstream, undo your changes by 5. `dub remove-local /path/to/the_package` 6. `dub remove-override the_package *` -- Bastiaan.
Re: DConf '22 Livestream Links
On Monday, 1 August 2022 at 12:45:56 UTC, Matheus wrote: On Monday, 25 July 2022 at 13:52:51 UTC, Mike Parker wrote: For those of you who can't join us in person at DConf '22 in London next week, you can join us instead via each day's livestream link: * Day 1: https://youtu.be/V6KFtzF2Hx8 Anyway I accessed the link and I don't know if it is a youtube limit, but as far I can go back, it starts with Walter talking about Octals. Was it the first part missing or is it a limit? The first part is missing due to a late click on the “go live” button. I assume the footage is still recorded, and will be part of the edited video. — Bastiaan.
Re: [i18n] Gettext 1.0.1 released
On Tuesday, 19 July 2022 at 20:20:29 UTC, Ogi wrote: Is this tested on Windows? Yes, it is developed on Windows. Do the included tests work for you? ``` Target is a library. Skipping execution. ``` That is not right. Are you developing a library or an application? If you cannot get it to work, feel free to [open an issue](https://github.com/veelo/gettext/issues) and include your `dub.json`. -- Bastiaan.
Re: Blog post on extending attribute inference to more functions
On Sunday, 17 July 2022 at 18:33:47 UTC, AnimusPEXUS wrote: I've just coded something and come with the idea of @todo/@fixme/@issueid attributes, so compiler write messages each time it finds those. Just as a thought.. maybe It can be useful, although it's already can be done with pragma(msg, "txt").. I abuse `@deprecated` for that purpose in my own code, to remind myself of some holes that need patching. — Bastiaan.
[i18n] Gettext 1.0.1 released
Two years ago, H. S. Teoh presented a proof of concept for
[automatic extraction of gettext-style translation
strings](https://forum.dlang.org/post/mailman.2526.1585832475.31109.digitalmar...@puremagic.com). I recently combined that idea with the existing [mofile](https://code.dlang.org/packages/mofile) package for reading translation tables in GNU gettext format, and the result is a feature rich solution for the support of multiple natural languages in D applications: https://code.dlang.org/packages/gettext. Perhaps not surprisingly, it can do more than GNU gettext itself.
I'd like to thank Steven Schveighoffer and Adam Ruppe for
[valuable forum
assistance](https://forum.dlang.org/post/afkbwsdrspndwgkai...@forum.dlang.org), and SARC B.V. for sponsoring. Some extracts from the [readme](https://github.com/veelo/gettext#readme) are included below:
# Features
- Concise translation markers that can be aliased to your
preference.
- All marked strings that are seen by the compiler are extracted
automatically.
- All (current and future) [D string literal
formats](https://dlang.org/spec/lex.html#string_literals) are
supported.
- Static initializers of fields, constants, immutables, manifest
constants and anonimous enums can be marked as translatable (a D
specialty).
- Concatenations of translatable strings, untranslated strings
and single chars are supported, even in initializers.
- Arrays of translatable strings are supported, also when
statically initialized.
- Plural forms are language dependent, and play nice with format
strings.
- Multiple identical strings are translated once, unless they are
given different contexts.
- Notes to the translator can be attached to individual
translatable strings.
- Code occurrences of strings are communicated to the translator.
- Available languages are discovered and selected at run-time.
- Platfom independent, not linked with C libraries.
- Automated generation of the translation table template.
- Automated merging into existing translations (requires [GNU
`gettext` utilities](https://www.gnu.org/software/gettext/)).
- Automated generation of binary translation tables (requires
[GNU `gettext` utilities](https://www.gnu.org/software/gettext/)).
- Includes utility for listing unmarked strings in the project.
# Usage
## Marking strings
Prepend `tr!` in front of every string literal that needs to be
translated. For instance:
```d
writeln(tr!"This string is to be translated");
writeln("This string will remain untranslated.");
```
## Plural forms
Sentences that should change in plural form depending on a number
should supply both singlular and plural forms with the number
like this:
```d
// Before:
writefln("%d green bottle(s) hanging on the wall", n);
// After:
writeln(tr!("one green bottle hanging on the wall",
"%d green bottles hanging on the wall")(n));
```
Note that the format specifier (`%d`, or `%s`, etc.) is optional
in the singular form.
Many languages have not just two forms like the English language
does, and translations in those languages can supply all the
forms that the particular language requires. This is handled by
the translator, and is demonstrated in [the example
below](https://github.com/veelo/gettext#example-1).
## Custom markers
If `tr` is too verbose for you, you can change it to whatever you
want:
```d
import gettext : _ = tr;
writeln(_!"No green bottles...");
```
## Marking format strings
Translatable strings can be format strings, used with
`std.format` and `std.stdio.writefln` etc. These format strings
do support plural forms, but the argument that determines the
form must be supplied to `tr` and not to `format`. The
corresponding format specifier will not be seen by `format` as it
will have been replaced with a string by `tr`. Example:
```d
format(tr!("Welcome %s, you may make a wish",
"Welcome %s, you may make %d wishes")(n), name);
```
The format specifier that selects the form is the last specifier
in the format string (here `%d`). In many sentences, however, the
specifier that should select the form cannot be the last. In
these cases, format specifiers must be given a position argument,
where the highest position determines the form:
```d
foreach (i, where; [tr!"hand", tr!"bush"])
format(tr!("One bird in the %1$s", "%2$d birds in the
%1$s")(i + 1), where);
```
Again, the specifier with the highest position argument will
never be seen by `format`. On a side note, some translations may
need a reordering of words, so translators may need to use
position arguments in their translated format strings anyway.
Note: Specifiers with and without a position argument must not be
mixed.
## Concatenations
Translators will be able to produce the best translations if they
get to work with full sentences, like
```d
auto message = format(tr!`Could not open the file "%s" for
reading.`, file);
```
However, in support of legacy code, concatenations of strings do
Re: How do I download the Windows DMD installer?
On Sunday, 17 July 2022 at 19:58:03 UTC, LeMondaide wrote: When I try (https://dlang.org/ or https://dlang.org/download.html) I am sent here: https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2022/dmd-2.100.1.exe and get this message "AccessDeniedAccess Denied4TMZ12PKCBCER6SAQQ7FpshcuoQ3ied0qGEHZ+lSz+qD9+aJmqH24qD5pkCWrGANGD6Lk6eT5d4wAG1n3kYvhWNJsig=" I have not found an alternative download location. The download for 2.100.1 is currently broken. Find 2.100.0 from http://downloads.dlang.org/releases/2022/ for now. -- Bastiaan.
Re: Null terminated character
On Thursday, 23 June 2022 at 16:16:26 UTC, vc wrote: I've try this '\0'*10 and didn't work, i want the results be \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 ```d string nulls = '\0'.repeat(10).array; ``` — Bastiaan.
Re: Why allow initializers of non-static members that allocate?
On Saturday, 11 June 2022 at 10:52:58 UTC, Mike Parker wrote: I agree with your initial assessment that it should be an error. It really only makes sense to allow the dynamic allocation if the fields are immutable and, in the case of arrays, the initializer is a literal.
Re: Why allow initializers of non-static members that allocate?
On Saturday, 11 June 2022 at 01:52:58 UTC, Mike Parker wrote: People getting bit by `new` in field initialization often enough that I think a warning would be helpful. The problem is so much bigger because it is not just a case of being aware not to use `new` in member initialisers. As you see in my second example in https://forum.dlang.org/post/ogvubzgprghefclgl...@forum.dlang.org there is no `new` anywhere. In fact you could say an effort has been made to do the right thing in `struct A` where the allocation has been moved to the constructor (a strategy that is not always available because structs don’t have default constructors) yet we fell into the same trap. My point is that this problem can be buried deep down under multiple layers and you can’t really ever be sure that there isn’t a problem in your massive code base. But any such warnings need to be enabled by default to be useful, and must have an off switch for people who don't need them. So the question in each case would be, where's the line between helpful and annoying? So that’s why I used “why” in the title of this thread, which I haven’t seen an answer to yet. What is the practical case where that warning would be annoying? When would you actually want this behaviour? — Bastiaan.
Re: Why allow initializers of non-static members that allocate?
On Friday, 10 June 2022 at 14:56:24 UTC, Steven Schveighoffer wrote: On 6/10/22 3:46 AM, Mike Parker wrote: I think this is a case where having a warning that's on by default, and which can be explicitly disabled, is useful. "Blah blah .init blah blah. See link-to-something-in-docs. Is this what you intended?" Here the language is being extremely unsafe. Not only is the field shared between instances, it's shared across instances in *different threads*. Discovered circa 2009: https://issues.dlang.org/show_bug.cgi?id=2947 Thanks for the pointer. #dbugfix 2947 It should be illegal to declare a field this way that has mutable references without being `shared`. End of story.
Re: Why allow initializers of non-static members that allocate?
On Friday, 10 June 2022 at 07:49:43 UTC, Mike Parker wrote: And it *is* documented: Struct fields are by default initialized to whatever the Initializer for the field is, and if none is supplied, to the default initializer for the field's type. The default initializers are evaluated at compile time. https://dlang.org/spec/struct.html#default_struct_init Yes, that section I find open for interpretation, because I don't think pointer values can be determined at compiler time. I assume S.init is constructed at program initialization, which is then blitted into any new instance of S. -- Bastiaan.
Re: Why allow initializers of non-static members that allocate?
On Friday, 10 June 2022 at 07:46:36 UTC, Mike Parker wrote: On Friday, 10 June 2022 at 07:35:17 UTC, Bastiaan Veelo wrote: Is there a use case where this makes sense? I would have much appreciated the compiler slapping me on the fingers, but it doesn't. I understand that it is safe and that the compiler can allow this, but why would anyone want that? D-scanner does not check for this either. Any initialization of a member field is overriding the field's `.init` value for the type. If a dynamic allocation set a different value per instance, then you'd have inconsistent behavior with, e.g., `int a = 5`. Yes, I understand that the compiler can't do what I was expecting it to do, it was a mistake. I think a helpful error message would be: "Error: The initializer `A(5)` allocates memory that is shared among all instances of `S`. If you want that, make `S.a` `static`." I understand that it's not something that people expect, but making it an error can't be the answer. And making it a static field is not the same thing. It's not the same thing, therefore I was hoping to see a use case for it -- but just because I'm curious; Preventing the mistake is my main thing. I think this is a case where having a warning that's on by default, and which can be explicitly disabled, is useful. "Blah blah .init blah blah. See link-to-something-in-docs. Is this what you intended?" That would be fine too. By the way, if there is something-in-docs, I don't think it is prominent enough... -- Bastiaan.
Why allow initializers of non-static members that allocate?
I have been foolish enough to make a mistake like this:
```d
struct S
{
int[] arr = new int[](5);
}
```
This is terrible because
```d
S s1;
S s2;
s2.arr[0] = 42;
writeln(s1.arr[0]); // 42 Gotcha!
```
Of course there are less obvious variants of the same mistake:
```d
import std;
struct S
{
A a = A(5);
}
struct A
{
int[] arr;
this (int l)
{
arr.length = l;
}
}
void main()
{
S s1;
S s2;
s2.a.arr[0] = 42;
writeln(s1.a.arr[0]); // 42 :-(
}
```
Is there a use case where this makes sense? I would have much
appreciated the compiler slapping me on the fingers, but it
doesn't. I understand that it is safe and that the compiler can
allow this, but why would anyone want that? D-scanner does not
check for this either.
I think a helpful error message would be: "Error: The initializer
`A(5)` allocates memory that is shared among all instances of
`S`. If you want that, make `S.a` `static`."
-- Bastiaan.
Re: cogito, cognitive complexity for D
On Tuesday, 24 May 2022 at 21:25:38 UTC, Christian Köstlin wrote: if the dmd frontend could be made available as a dub package, It already is, as sub package of https://code.dlang.org/packages/dmd — Bastiaan.
Re: Library for image editing and text insertion
On Wednesday, 27 April 2022 at 09:27:24 UTC, Alexander Zhirov wrote: Now I would like to reduce the size of the executable file and it would be great at all! Try the `-release` option to `dmd`. Or use LDC. -- Bastiaan.
Re: Language server
On Tuesday, 26 April 2022 at 18:15:57 UTC, Alain De Vos wrote: In a perfect world there would be someone uploading a youtube video how to implement neovim with a dlang language-server. With function-completions-help where hints are given about the functions and libraries. If anyone could do this , this would be nice to have. I'm not a vim user, but there is this: https://wiki.dlang.org/D_in_Vim If that is what you needed to get what you want, maybe make a YouTube video about it ;-) -- Bastiaan.
Re: Beta 2.100.0
On Friday, 22 April 2022 at 09:24:00 UTC, Martin Nowak wrote: http://dlang.org/changelog/2.100.0.html It seems the list of contributors does not include the contributions to Dub. — Bastiaan.
Re: How to use Vector Extensions in an opBinary
On Thursday, 21 April 2022 at 15:31:04 UTC, HuskyNator wrote: On Sunday, 17 April 2022 at 17:04:57 UTC, Bastiaan Veelo wrote: You might want to have a look at https://code.dlang.org/packages/intel-intrinsics — Bastiaan. This does not discuss core.simd or __vector type, or did I miss/mininterpret something? It wraps `core.simd` with an eye on portability. I haven’t used it myself, but my impression is that if you’re interested in `core.simd`, intel-intrinsics may be a better option. I think there is also better documentation. There is a video of a DConf presentation that you may want to watch. — Bastiaan.
Re: Can Enums be integral types?
On Tuesday, 19 April 2022 at 01:25:13 UTC, Era Scarecrow wrote:
The 'integral' or numeric value is used for uniqueness, […]
There is nothing that requires enum values to be unique, though:
```d
import std;
void main()
{
enum E {Zero = 0, One = 0, Two = 0}
writeln(E.Two); // Zero!
}
```
— Bastiaan.
Re: Can Enums be integral types?
On Saturday, 16 April 2022 at 11:39:01 UTC, Manfred Nowak wrote:
In the specs(17) about enums the word "integral" has no match.
But because the default basetype is `int`, which is an integral
type, enums might be integral types whenever their basetype is
an integral type.
On the other hand the specs(7.6.5.3) about types say
| A bool value can be implicitly converted to any integral type,
| with false becoming 0 and true becoming 1.
This seems senseless, when the enum has no names defined for
one of these values.
Not sure where the question is, but
[6.5.3](https://dlang.org/spec/type.html#bool) makes that this
works:
```d
int i = true; // 1
```
However this does not:
```d
enum E : int {Zero, One, Two}
E e1 = true; // Error: cannot implicitly convert expression
`true` of type `bool` to `E`
E e2 = 1; // Error: cannot implicitly convert expression `1` of
type `int` to `E`
```
The reason is in [17.1.5](https://dlang.org/spec/enum.html):
“EnumBaseType types cannot be implicitly cast to an enum type.”
— Bastiaan.
Re: How to use Vector Extensions in an opBinary
On Sunday, 17 April 2022 at 11:16:25 UTC, HuskyNator wrote: I recently found out there is [support for vector extensions](https://dlang.org/spec/simd.html) But I have found I don't really understand how to use it, not even mentioning the more complex stuff. I couldn't find any good examples either. You might want to have a look at https://code.dlang.org/packages/intel-intrinsics — Bastiaan.
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 10:59:39 UTC, Mike Parker wrote: ### D ecosystem services While we were waiting for everyone to arrive, I gave an update on the status of our plans to bring all of the ecosystem services under our control. At that point, I had received information on the resource requirements of services maintained by Vladimir Panteleev (the D forums, D wiki, and more), Jan Knepper (the main dlang.org site, the newsgroup server, the D blog), and Petar Kirov (run.dlang.io and tour.dlang.io). I also had received affirmative responses from those three to my invitation to join our next server meeting. Since that time, I have also received the same from Sönke Ludwig (code.dlang.org). The dub documentation, hosted at https://dub.pm should also be in that list. Currently there is a problem updating that site, see https://github.com/dlang/dub-docs/issues/41. -- Bastiaan.
Re: D Language Foundation Monthly Meeting for February 2022
On Saturday, 5 March 2022 at 14:03:38 UTC, Mike Parker wrote: On Saturday, 5 March 2022 at 12:39:39 UTC, Bastiaan Veelo wrote: On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote: But we have no reason to move the D projects away from GitHub to GitLab. GitLab has never entered the conversation. Two reasons would be that 1) It already offers [an integration with bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html). 2) Being open source it can be installed on your own hardware, which is the main argument being made for using bugzilla. It also has integrated CI. — Bastiaan. I have no opinion on point #1, but for #2, I do not see that as a benefit. We're aiming to integrate all of our services. As I see it, the less we have to manage ourselves, the better. If we did for some reason want to migrate to GitLab, my vote would be to let them host us. But my point was, GitHub has worked well for us for years. There's no desire to move away that I'm aware of. If it ain't broke, don't fix it! Definitely. Personally I think moving the tickets to GitHub is a good idea, I just felt these points needed to be made for completeness. — Bastiaan.
Re: D Language Foundation Monthly Meeting for February 2022
On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote: But we have no reason to move the D projects away from GitHub to GitLab. GitLab has never entered the conversation. Two reasons would be that 1) It already offers [an integration with bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html). 2) Being open source it can be installed on your own hardware, which is the main argument being made for using bugzilla. It also has integrated CI. — Bastiaan.
Re: D Language Foundation Monthly Meeting for February 2022
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote: ## Monthly Meeting Just letting you know that it is posts like these that I look forward to the most, and I very much appreciate the work that goes into them. Thanks! — Bastiaan.
Re: package libs on windows
On Tuesday, 1 February 2022 at 21:17:09 UTC, Abby wrote: I would like to know if there is a way to set path to lib to downloaded with package instead of harcoded. That’s documented on the [package page](https://code.dlang.org/packages/d2sqlite3). Are you trying to link with a separately downloaded version, or de included version? How have you configured your `dub.json`, and do you supply any options in the `dub` invocation? — Bastiaan.
Re: std.signals: Why emit() not extist?
On Thursday, 30 December 2021 at 19:13:10 UTC, Marcone wrote: I get this error: Error: undefined identifier `emit`, did you mean function `exit`? Did you `import std.signals`? — Bastiaan.
Re: First time using Parallel
On Sunday, 26 December 2021 at 15:20:09 UTC, Bastiaan Veelo wrote: So if you use `workerLocalStorage` to give each thread an `appender!string` to write output to, and afterwards write those to `stdout`, you'll get your output in order without sorting. Scratch that, I misunderstood the example. It doesn't solve ordering. The example works because order does not matter for addition. Sorry for spreading wrong information. -- Bastiaan.
Re: First time using Parallel
On Sunday, 26 December 2021 at 06:10:03 UTC, Era Scarecrow wrote:
[...]
```d
foreach(value; taskPool.parallel(range) ){code}
```
[...]
Now said results are out of order
[...]
So I suppose, is there anything I need to know? About shared
resources or how to wait until all threads are done?
Have a look at `taskPool.workerLocalStorage`. I learned about
this in [a post by data
pulverizer](https://forum.dlang.org/post/ddgxqoitxoaljfwnl...@forum.dlang.org), who gives this example (slightly modified):
```d
import std.traits : isFloatingPoint;
auto dot(T)(T[] x, T[] y) if (isFloatingPoint!T)
in (y.length == x.length)
{
import std.range : iota;
import std.parallelism : parallel, taskPool;
auto sums = taskPool.workerLocalStorage(0.0L);
foreach (i; parallel(iota(x.length)))
sums.get += x[i] * y[i];
T result = 0.0;
foreach (threadResult; sums.toRange)
result += threadResult;
return result;
}
void main()
{
double[] x = [1, 2, 3, 4, 5];
double[] y = [6, 7, 8, 9, 10];
assert(dot(x, y) == 130);
}
```
(https://run.dlang.io/is/Ia8A0k)
So if you use `workerLocalStorage` to give each thread an
`appender!string` to write output to, and afterwards write those
to `stdout`, you'll get your output in order without sorting.
--Bastiaan.
Re: Printed version of the Vibe.d tutorial
On Sunday, 19 December 2021 at 21:57:50 UTC, Rey Valeza wrote: Hi, The printed version of the Vibe.d tutorial 'Build web apps in Vibe.d by learning from a learner' which I uploaded earlier in February this year is now available in paperback at Amazon: https://www.amazon.com/dp/B09MYTMNKF If you find yourself printing loose pages here and there from the tutorial and wishing you had a book instead, this is the answer. Thanks! Should probably be in this list: https://wiki.dlang.org/Books — Bastiaan.
Re: Why does is the RandomAccessInfinite interface not a valid RandomAccessRange?
On Sunday, 19 December 2021 at 09:19:31 UTC, D Lark wrote: Do you know if there's a nightly version I can specify to use your fix? Are you inheriting from `RandomAccessInfinite`? Then you can probably add ```d static if (__VERSION__ < 2099) enum bool empty = false; ``` to make it work. — Bastiaan.
Re: DMD32 D Compiler v2.097.2-dirty ?
On Monday, 6 September 2021 at 15:37:31 UTC, Paul wrote: I like to write CLEAN code:) Why does my DMD installation say v2.097.2-dirty? https://forum.dlang.org/post/qqxmnoshytmzflviw...@forum.dlang.org I suppose it is due to how the scripts work that produce the compiler release. I guess these can be found online somewhere; Martin Nowak has been taking care of the releases for many years. I agree that it would look better to “clean this up”, but knowing that it is just cosmetics most people have more pressing tasks at hand… It looks like it would be easy enough for anyone to fix, though :-) — Bastiaan.
Re: Curious effect with traits, meta, and a foreach loop ... mystifies me.
On Tuesday, 7 September 2021 at 17:24:34 UTC, james.p.leblanc
wrote:
```d
/*…*/
// this is fine (notice that 'val' is never used
foreach( i, val ; u.tupleof ){
ptr = u.tupleof[i].x.ptr;
writeln("ptr: ", ptr);
}
// this fails with: "Error: variable 'i' cannot be read at
compile time
//
// foreach( i ; 0 .. 3 ){
//ptr = u.tupleof[i].x.ptr;
//writeln("ptr: ", ptr);
// }
}
```
As Adam mentioned `tupleof` only exists at compile time, and a
`foreach` over a `tupleof` gets unrolled at compile time, akin to
a `static foreach`. Consequently you can make your snippet work
by prepending `static` (and fixing the range):
```d
static foreach (i; 0 .. u.tupleof.length) {
ptr = u.tupleof[i].x.ptr;
writeln("ptr: ", ptr);
}
```
https://run.dlang.io/is/T6jrjf
Not sure if that helps in what you’re trying to achieve though,
as that isn’t clear to me.
—Bastiaan.
Re: implimenting interface function by inheriting from other class
On Saturday, 21 August 2021 at 20:35:43 UTC, Alexey wrote:
Hello
```D
interface Int
{
void coolFunc();
}
class C1
{
void coolFunc()
{
return;
}
}
class C2 : C1, Int
{
}
void main()
{
auto c = new C2;
}
```
dmd says it's not Ok:
t.d(14): Error: class `t.C2` interface function `void
coolFunc()` is not implemented
how to make dmd happy?
Not sure if this is the best way, but it does make dmd happy:
https://run.dlang.io/is/44F3AE
```d
class C2 : C1, Int
{
override void coolFunc()
{
C1.coolFunc;
}
}
```
It looks lame, I admit.
— Bastiaan.
Re: simple (I think) eponymous template question ... what is proper idimatic way ?
On Tuesday, 17 August 2021 at 20:29:51 UTC, james.p.leblanc wrote:
So, below
is my code:
import std.stdio;
import std.meta : AliasSeq;
template isAmong(T, S...) {
static if (S.length == 0)
enum isAmong = false;
else
enum isAmong = is(T == S) || isAmong(T, S[1..$]);
}
alias MyTypes = AliasSeq!(int, float);
auto myFunc(T)(T a, T b) if (isAmong!(T, MyTypes)) {
writeln(" in myFunc ");
return;
}
void main(){
writeln("started ...");
auto a = 1;
auto b = 2;
myFunc!(int)(a, b);
return;
}
And, here are the error message:
(master) Notes > dmd recursive_template.d
recursive_template.d(9): Error: circular reference to variable
`recursive_template.isAmong!(int, int, float).isAmong`
recursive_template.d(17): Error: template instance
`recursive_template.isAmong!(int, int, float)` error
instantiating
recursive_template.d(29):while looking for match for
`myFunc!int`
Can anyone see what is going on?
Best Regards,
James
https://run.dlang.io/is/m5svQ2
The error was in line 8.
T (Teoh) forgot to take the first of `S` in `is(T == S[0])`. The
error message improves after adding the `!` in `isAmong!(T,
S[1..$])`, which, surprisingly, is optional!
— Bastiaan.
Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...
On Sunday, 15 August 2021 at 20:41:51 UTC, james.p.leblanc wrote:
struct A
{
int opIndexAssign(int v); // overloads a[] = v
int opIndexAssign(int v, size_t[2] x); // overloads
a[i .. j] = v
int[2] opSlice(size_t x, size_t y); // overloads i
.. j
}
void test()
{
A a;
int v;
a[] = v; // same as a.opIndexAssign(v);
a[3..4] = v; // same as a.opIndexAssign(v,
a.opSlice(3,4));
}
I have hacked at this trying to get a simple working example.
Not sure if this does enough of what you’re looking for, but this
covers the minimal steps to get it working:
https://run.dlang.io/is/m5svQ2
```d
import std;
struct A
{
int opIndexAssign(int v) // overloads a[] = v
{
writeln(__FUNCTION__);
return 42;
}
int opIndexAssign(int vh, size_t[2] x) // overloads a[i ..
j] = v
{
writeln(__FUNCTION__);
return 43;
}
int[2] opSlice(size_t x, size_t y) // overloads i .. j
{
writeln(__FUNCTION__);
return [44, 45];
}
}
void main()
{
A a;
int v;
a[] = v; // same as a.opIndexAssign(v);
a[3..4] = v; // same as a.opIndexAssign(v, a.opSlice(3,4));
}
```
— Bastiaan.
Re: D has the same memory model as C++
On Wednesday, 11 August 2021 at 05:33:06 UTC, Tejas wrote: On Tuesday, 10 August 2021 at 21:19:39 UTC, Bastiaan Veelo wrote: On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote: Basically, what are the subtle gotcha's in the differences between C++ and D code that looks similar The only gotcha that comes to my mind is that `private` means private to the module in D, not private to the aggregate. — Bastiaan. A few others that I know: When importing one module(say ```m2```) into another (say ```m1```), the symbols of ```m1``` aren't automatically visible in ```m2```. You must import ```m1``` in ```m2``` for that. How is that different from C++? I think you meant to say that if `m1` imports `m2`, the symbols of `m2` don't automatically become visible by importing `m1`. Indeed you also have to import `m2` for that, *unless* `m1` `public`ly imports `m2`. You can't just initialize variables willy-nilly in a module, you must do them inside ```static this()``` Or declare them with an initial value. I'm not aware of a rule that requires module level variables to be initialized in `static this()`, but if you require them to be initialized at startup with a value not known at compile time, then that is the place to do it. I don't think you can go about this willy-nilly in C++ either... Method function pointers don't exist in D, equivalent functionality is achieved by using a delegate that captures the context of a class instantiated object. To use a function pointer explicitly, you can't just write ```(func)(arguments)```, it is ```()(arguments)```(thank you evilrat) To take the address of a method (in order to assign it to a delegate) requires `&`, yes, but not when calling the delegate. --Bastiaan.
Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 18:13:17 UTC, Tejas wrote: On Tuesday, 10 August 2021 at 18:07:35 UTC, Bastiaan Veelo wrote: On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote: there's casting away const, a clearly seperate language feature which has no equivalent in D; You *can* cast away `const` in D: https://run.dlang.io/is/sWa5Mf — Bastiaan. Yes, but it is UB, not defined and supported by the standard/implementation. OK, strictly speaking casting away `const` is in the language, but modifying after that is UB. https://dlang.org/spec/const3.html#removing_with_cast — Bastiaan.
Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote: Basically, what are the subtle gotcha's in the differences between C++ and D code that looks similar The only gotcha that comes to my mind is that `private` means private to the module in D, not private to the aggregate. — Bastiaan.
Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote: there's casting away const, a clearly seperate language feature which has no equivalent in D; You *can* cast away `const` in D: https://run.dlang.io/is/sWa5Mf — Bastiaan.
Re: Error when compile with DMD using -m64?
On Tuesday, 10 August 2021 at 17:13:31 UTC, Marcone wrote: On Tuesday, 10 August 2021 at 15:55:42 UTC, Bastiaan Veelo wrote: Use `size_t` and `ptrdiff_t` instead to make your program compile in both 32 bit and 64 bit modes. https://dlang.org/spec/type.html#aliased-types -- Bastiaan. Thank you very much! Your information was very precious! It worked very well! Now I can create x32 or x64 compatible programs without creating two codes. You’re welcome :-) — Bastiaan.
Re: Error when compile with DMD using -m64?
On Tuesday, 10 August 2021 at 01:29:04 UTC, Marcone wrote: Solved converting long and int. Use `size_t` and `ptrdiff_t` instead to make your program compile in both 32 bit and 64 bit modes. https://dlang.org/spec/type.html#aliased-types -- Bastiaan.
Re: How Add Local modules mymodule.d using DUB?
On Monday, 9 August 2021 at 16:32:13 UTC, Marcone wrote: My main program need import a local module called mymodule.d. How can I add this module using DUB? Thank you. Let’s assume you just created a dub project in `myproject` with `dub init`. Place `mymodule.d` alongside `app.d` in `myproject/source`. Now you can `import mymodule` in `app.d`. Dub takes care of the linking. — Bastiaan.
Re: writef, compile-checked format, pointer
On Monday, 9 August 2021 at 22:01:18 UTC, Patrick Schluter wrote:
On Monday, 9 August 2021 at 19:38:28 UTC, novice2 wrote:
format!"fmt"() and writef!"fmt"() templates
with compile-time checked format string
not accept %X for pointers,
but format() and writef() accept it
https://run.dlang.io/is/aQ05Ux
```
void main() {
import std.stdio: writefln;
int x;
writefln("%X", ); //ok
writefln!"%s"(); //ok
//writefln!"%X"(); //compile error
}
```
is this intentional?
Yes. %X is to format integers.
It is to format pointers as well, according to the last table on
https://dlang.org/phobos/std_format.html.
|Type|Format character|Formatted as|
|-|-|-|
|Pointer| 's' |A null pointer is formatted as 'null'. All other
pointers are formatted as hexadecimal numbers with the format
character 'X'.|
| |'x', 'X' |Formatted as a hexadecimal number.|
It looks like a bug to me.
— Bastiaan.
Re: Exit before second main with -funittest
On Friday, 30 July 2021 at 05:51:41 UTC, Brian Tiffin wrote: [... interesting account of the D experience ...] **Kudos team and contributors.** Can't really suggest that many improvements to resources needed for learning D, as a hobbyist not on a clock, being new still and low enough to not know what detail interactions might be less approachable. So far, very approachable. Not confusing, but tantalizing caves to explore and integrate into knowing about potentials, super powers, and dark corners that may need to be accounted for. And friendly people to pester with random brain train new here questions. Have good, make well, and thanks. I enjoyed reading all of that. -- Bastiaan.
Re: D Language Foundation Quarterly Meeting Summary -- July 23, 2021
On Wednesday, 28 July 2021 at 06:37:56 UTC, Mike Parker wrote: * Joseph Rushton Wakeling representing Frequenz I know Joseph, but haven't heard of Frequenz. Can't find them on https://dlang.org/orgs-using-d.html. Is there any news to be announced? -- Bastiaan.
Re: how to make D program footprint smaller ?
On Friday, 9 July 2021 at 03:07:04 UTC, dangbinghoo wrote: as questioned in the previous thread, I need to find out something like `--as-needed` options available for D. You are probably looking for the [-i](https://dlang.org/dmd-osx.html#switch-i%5B) compiler option. As far as I know `dub` is not devised to work with that, so making use of it can be finicky. I have managed to get it to work on a `sourceLibrary` that we control, not sure how applicable it is on a third party package. — Bastiaan.
Re: Diva - D Language Interface for Versioned Applications
On Saturday, 10 July 2021 at 11:29:21 UTC, pineapple wrote: On Saturday, 10 July 2021 at 08:42:46 UTC, Bastiaan Veelo wrote: Could it be that you have overlooked D Version Manager? https://code.dlang.org/packages/dvm — Bastiaan. Oh, I hadn't picked up on that. That only manages DMD, though. Diva can manage DMD and LDC, as well as managing dub separately if you want it to. Personally I'll be using Diva in the future to manage my installations. Thanks for clarifying the differences. — Bastiaan.
Re: Diva - D Language Interface for Versioned Applications
On Friday, 9 July 2021 at 23:59:55 UTC, pineapple wrote: Basically, it's a version manager which currently supports DMD, LDC, and dub. It's rough, but maybe in some ways a little less rough than install.sh, at https://dlang.org/install.html https://github.com/pineapplemachine/diva Could it be that you have overlooked D Version Manager? https://code.dlang.org/packages/dvm — Bastiaan.
Re: Can I get the time "Duration" in "nsecs" acurracy?
On Friday, 9 July 2021 at 21:13:02 UTC, rempas wrote: On Friday, 9 July 2021 at 20:54:21 UTC, Paul Backus wrote: On Friday, 9 July 2021 at 20:43:48 UTC, rempas wrote: I'm reading the library reference for [core.time](https://dlang.org/phobos/core_time.html#Duration) and It says that the duration is taken in "hnsecs" and I cannot understand if we can change that and choose the precision. Does anyone know if we can do that? It is stored internally in "hnsecs", but you can convert it to other units using the `total` method [1]; for example, `myDuration.total!"nsecs"`. [1] https://dlang.org/phobos/core_time.html#.Duration.total It doesn't work for me. I have the following code: ``` MonoTime start = MonoTime.currTime(); // Doing stuff MonoTime end = MonoTime.currTime(); Duration dur = end - start; dur = dur.total!"nsecs"; ``` and I get the following error message: "Error: cannot implicitly convert expression \`dur.total()\` of type \`long\` to \`Duration`" You cannot change the precision of `Duration`, it always counts in multiples of 100 nsecs. You can count how many multiples of other units fit into the same `Duration` using `total`, but it will just return a number, not a “converted” `Duration`. `toString` will produce an easy readable string (more or less), as in https://run.dlang.io/is/baqKLG, where “hnsec” is the smallest unit. If you think hectonanosecond is a weird unit, then [you are not alone](https://forum.dlang.org/post/pwotyniksrskdzmea...@forum.dlang.org), and it [has been pointed out](https://forum.dlang.org/post/khppfxsyfefjksvri...@forum.dlang.org) that it does not comply with SI. — Bastiaan.
Re: Is there an alias for standard libraries to use in import statement?
On Sunday, 4 July 2021 at 07:40:44 UTC, BoQsc wrote:
I just started with a fresh look at the D language and would
like to be able to rewrite this code:
import std;
void main()
{
writeln("Hello D");
}
Into more readable standard library name:
import system;
void main()
{
writeln("Hello D");
}
That is [easy](https://run.dlang.io/is/af8dMY), just define the
`system` module and publicly `import std`:
--- test.d
```d
import system;
void main()
{
writeln("Hello D");
}
```
--- system.d
```d
module system;
public import std;
```
But like Mike, I advise against this. It will confuse every D
programmer that is trying to read your code. What is most natural
depends heavily on your background and what language you are
coming from. `std` is perfectly natural if you're coming from C++.
Fun fact (but equally ill advised): You can hide the entire
import from view like this:
```d
void main()
{
writeln("Hello D");
}
/* Lean on Enter for a while */
import std;
```
-- Bastiaan.
Re: Printing Tuple!(...)[] using for loop?
On Friday, 2 July 2021 at 04:21:24 UTC, Kirill wrote: I have a `Tuple!(string, ..., string)[] data` If there are only strings in the tuple, it could be simplified by making it a static array of strings instead. The compile-time index issue would go away. —Bastiaan
Re: How to call stop from parallel foreach
On Thursday, 24 June 2021 at 20:56:26 UTC, Ali Çehreli wrote: On 6/24/21 1:33 PM, Bastiaan Veelo wrote: > distributes the load across all cores (but one). Last time I checked, the current thread would run tasks as well. Ali Indeed, thanks. — Bastiaan.
Re: How to call stop from parallel foreach
On Thursday, 24 June 2021 at 21:05:28 UTC, Bastiaan Veelo wrote: On Thursday, 24 June 2021 at 20:41:40 UTC, seany wrote: Is there any way to control the number of CPU cores used in parallelization ? E.g : take 3 cores for the first parallel foreach - and then for the second one, take 3 cores each -> so 3 + 3 * 3 = 12 cores out of a 16 core system? Thank you. There might be, by using various `TaskPool`s with a smaller number of work threads: https://dlang.org/phobos/std_parallelism.html#.TaskPool.this.2. But I cannot see the benefit of doing this. It will just distribute the same amount of work in a different way. Actually, I think this would be suboptimal as well, as the three outer threads seem to do no real work. — Bastiaan.
Re: How to call stop from parallel foreach
On Thursday, 24 June 2021 at 20:41:40 UTC, seany wrote:
On Thursday, 24 June 2021 at 20:33:00 UTC, Bastiaan Veelo wrote:
By the way, nesting parallel `foreach` does not make much
sense, as one level already distributes the load across all
cores (but one). Additional parallelisation will likely just
add overhead, and have a net negative effect.
— Bastiaan.
Okey. So consider :
foreach(array_elem; parallel(an_array)) {
dothing(array_elem);
}
and then in `dothing()` :
foreach(subelem; array_elem) {
dootherthing(subelem);
}
- Will this ALSO cause the same overhead?
You can nest multiple `foreach`, but only parallelise one like so:
```d
foreach(array_elem; parallel(an_array))
foreach(subelem; array_elem)
dootherthing(subelem);
```
So there is no need to hide one of them in a function.
Is there any way to control the number of CPU cores used in
parallelization ?
E.g : take 3 cores for the first parallel foreach - and then
for the second one, take 3 cores each -> so 3 + 3 * 3 = 12
cores out of a 16 core system? Thank you.
There might be, by using various `TaskPool`s with a smaller
number of work threads:
https://dlang.org/phobos/std_parallelism.html#.TaskPool.this.2.
But I cannot see the benefit of doing this. It will just
distribute the same amount of work in a different way.
— Bastiaan.
Re: How to call stop from parallel foreach
On Thursday, 24 June 2021 at 18:23:01 UTC, seany wrote:
I have seen
[this](https://forum.dlang.org/thread/akhbvvjgeaspmjntz...@forum.dlang.org).
I can't call break form parallel foreach.
Okey, Is there a way to easily call .stop() from such a case?
Yes there is, but it won’t break the `foreach`:
```d
auto tp = taskPool;
foreach (i, ref e; tp.parallel(a))
{
// …
tp.stop;
}
```
The reason this does not work is because `stop` terminates the
worker threads as soon as they are finished with their current
`Task`, but no sooner. `parallel` creates the `Task`s before it
presents a range to `foreach`, so no new `Task`s are created
during iteration. Therefore all elements are iterated.
outer: foreach(i, a; parallel(array_of_a)) {
foreach(j, b; parallel(array_of_b)) {
By the way, nesting parallel `foreach` does not make much sense,
as one level already distributes the load across all cores (but
one). Additional parallelisation will likely just add overhead,
and have a net negative effect.
— Bastiaan.
Dub as tool chain installer
On Friday, 18 June 2021 at 06:14:03 UTC, Martin Nowak wrote: Maybe we could recruit someone to replace the dated NSIS installer with a native msi installer. https://issues.dlang.org/show_bug.cgi?id=15375 https://en.wikipedia.org/wiki/List_of_installation_software#Windows Don't have much of a clue about Windows nowadays, maybe there are more suitable alternatives. What would be the most suitable alternative in my eyes is for dub, based on [tool chain requirements](https://dub.pm/package-format-json.html#toolchain-requirements) specified in `dub.json`, to install and select compilers. Cross platform and cross vendor. I know there are compiler version managers, but I think since dub can check versions of packages and install packages, and can check compiler versions, it is only natural that it should also be able to install compilers. Above all, it would be just so convenient. This way a compiler upgrade becomes part of your commit history. You can test (beta) compiler releases in a separate branch, resolve deprecations comfortably, have your CI run all tests, all without interfering with main development. You push the change and all team members upgrade their compilers automatically without even noticing it, and certainly without surprises. And any number of years in the future, when you pick up an old project that has been dormant, it still compiles flawlessly because dub downgrades the compiler automatically. Come to think of it, maybe there should be an additional package category that provides build tools that can be run by dub without `dub run`, such as `dfmt`, `dpp`, `pegged`, and compilers and linters. — Bastiaan.
Re: Financial Library
On Sunday, 13 June 2021 at 12:46:29 UTC, Financial Wiz wrote: What are some of the best Financial Libraries for D? I would like to be able to aggregate as much accurate information as possible. Thanks. I am not into financials, but these libs show up in a search: https://code.dlang.org/search?q=Decimal. Perhaps you know some other relevant terms to search for. One of the [sponsors](https://dlang.org/foundation/sponsors.html) of dlang is Symmetry Investments, who run a hedge fund. Their use of D is pretty advanced, and includes many libs and utilities that are not limited to financial applications. These are the ones that I know of: https://code.dlang.org/search?q=Mir, https://code.dlang.org/packages/dpp, https://code.dlang.org/packages/pegged, https://code.dlang.org/packages/excel-d, https://github.com/symmetryinvestments. — Bastiaan.
Re: Inclusion of Parenthesis on Certain Functions
On Sunday, 13 June 2021 at 15:45:53 UTC, Justin Choi wrote: I've tried looking through the documentation but can't find an explanation for why you can use it without parenthesis. https://dlang.org/spec/function.html#optional-parenthesis (Some exceptions regarding delegates and function pointers exist.) —Bastiaan
Re: Dlang Setup Tutorials
On Thursday, 10 June 2021 at 18:11:45 UTC, Igor wrote: Hi, I made my first few video tutorials and they are about how to setup DLang development environment on Windows and Linux. Hopefully it can help new people quickly setup everything for playing around with our beautiful language :). [YouTube Intro](https://www.youtube.com/watch?v=OzASFrPzil4=PLNiswfy6ptAnw_QmqAuy-Bz02oeu4pnLL) [YouTube Windows install](https://www.youtube.com/watch?v=fuJBj_tgsR8=PLNiswfy6ptAnw_QmqAuy-Bz02oeu4pnLL=2) [YouTube Ubuntu install](https://www.youtube.com/watch?v=fJ-u29rDVXk=PLNiswfy6ptAnw_QmqAuy-Bz02oeu4pnLL=3) [YouTube Manjaro install](https://www.youtube.com/watch?v=rM6_S6Fy7aQ=PLNiswfy6ptAnw_QmqAuy-Bz02oeu4pnLL=4) [...] These are nicely done, bravo! Even I learned something new. -- Bastiaan.
Re: Release D 2.097.0
On Saturday, 5 June 2021 at 13:00:05 UTC, evilrat wrote: Windows installer is broken. I have install target path excluded from Windows Defender anti virus checks, yet after the installation it only contains .bat files, uninstaller.exe, dmd2/windows/lib64 and lib32mscoff, but no bin and sources. I am having issues as well, but I don't think the installer is at fault: I see the `C:\D\dmd2` directory get filled as the installer progresses, then files just disappear. It doesn't seem to be consistent though. After failure I tried with `dmd-2.096.1.exe` and the same thing happened, whereas it had installed fine before. I tried `dmd-2.097.0.exe` and this time the whole directory got wiped. I tried again and it installed fine. Windows 10 Pro N version 20H2 build 19042.985. I suspect MS cloud security scan. -- Bastiaan.
Re: coreutils with D trials, wc, binary vs well formed utf
On Monday, 24 May 2021 at 16:58:33 UTC, btiffin wrote:
[...]
Just bumped into
https://dlang.org/blog/2020/01/28/wc-in-d-712-characters-without-a-single-branch/
[...]
Is there a(n easy-ish) way to fix up that wc.d source in the
blog to fallback to byte stream mode when a utf-8 reader fails
an encoding?
Welcome, Brian.
I have allowed myself to use exception handling and `filter`,
which I regard to be no longer branch free. But it does (almost)
produce the same output as gnu wc:
```d
Line toLine(char[] l) pure {
import std.utf : UTFException, byChar;
import std.ascii : isWhite;
import std.algorithm : filter;
try {
return Line(l.byCodePoint.walkLength,
l.splitter.walkLength);
}
catch (UTFException) {
return Line(l.length, l.byChar.splitter!(isWhite).
filter!(w => w.length >
0).walkLength);
}
}
```
The number of chars can be returned in O(0) by the `.length`
property. Use of `byChar.splitter!(isWhite)` considers the ASCII
values of the chars, but without the `filter` it counts too many
words. The reason is that a mix of different white space
characters causes problems (https://run.dlang.io/is/QzjTN0):
```d
writeln("Hello \t D".splitter!isWhite); // ["Hello", "", "",
"D"]
writeln("Hello \t D".splitter); // ["Hello", "D"]
```
This surprises me, could be a bug.
So `filter!(w => w.length > 0)` filters out the "words" with zero
length...
Compared to gnu wc this reports one line too many for me, though.
There may be more elegant solutions than mine.
-- Bastiaan.
Re: Struct initialization extra comma - should it compile
On Sunday, 25 April 2021 at 13:39:54 UTC, JN wrote:
struct Foo
{
int x, y, z;
}
void main()
{
Foo bar = Foo(1,);
}
This compiles without syntax errors, is this expected?
Yes, the
[specification](https://dlang.org/spec/declaration.html#StructInitializer) is like this:
```
StructMemberInitializers:
StructMemberInitializer
StructMemberInitializer ,
StructMemberInitializer , StructMemberInitializers
```
— Bastiaan.
Re: When should I use SortedRange.release?
On Friday, 23 April 2021 at 21:34:39 UTC, Steven Schveighoffer wrote: `SortedRange` itself is kind of a kludge of "policy" that isn't fit for function. I use release to get the original data type out (via r.save.release), but that's about it. See my rant about it [here](https://forum.dlang.org/post/r7ia94$19uo$1...@digitalmars.com) -Steve Understood, thanks. --Bastiaan.
Re: When should I use SortedRange.release?
On Friday, 23 April 2021 at 18:35:25 UTC, Paul Backus wrote:
On Friday, 23 April 2021 at 17:35:13 UTC, Bastiaan Veelo wrote:
What happens when a range is released?
What happens if a range is not released?
What happens if a range is released more than once?
And what does "controlled" imply here? In what way has
`SortedRange` control over the underlaying data? What can I do
and what can't I do to the underlying data as long as
`SortedRange` has control?
I had to look at the source to figure this out. Fortunately,
the source is pretty simple:
https://phobos.dpldocs.info/source/std.range.d.html#L10833
Turns out, it just calls `core.lifetime.move`. So I guess when
the docs say "control", what they are really talking about is
ownership.
Practically speaking, this means that in generic code, we
should avoid using a `SortedRange` after calling `release`,
since we do not know whether the range is owning or non-owning
w.r.t. the underlying data.
Thanks. There is no word in the documentation about when
`SortedRange` would or would not be owning data, though, and
hence when `release` would be appropriate to call. To me
`release` seems to be calling `std.algorithm.mutation.move` , but
it is probably very similar to `core.lifetime.move`.
In case the underlying data is a slice, I think we end up at
https://phobos.dpldocs.info/source/std.algorithm.mutation.d.html#L1459, which I can't see accomplishes anything in [this example](https://dlang.org/phobos/std_algorithm_sorting.html#.sort) (except returning the slice that went in):
```d
int[] array = [ 1, 2, 3, 4 ];
// sort in descending order
array.sort!("a > b");
writeln(array); // [4, 3, 2, 1]
// sort in ascending order
array.sort();
writeln(array); // [1, 2, 3, 4]
// sort with reusable comparator and chain
alias myComp = (x, y) => x > y;
writeln(array.sort!(myComp).release); // [4, 3, 2, 1]
```
-- Bastiaan.
When should I use SortedRange.release?
For reference, `SortedRange.release` is [documented](https://dlang.org/phobos/std_range.html#.SortedRange) as such: "Releases the controlled range and returns it." Wow thanks! I love functions that are named exactly as what they do ;-) Seriously though, I still don't know what it is that it does, and why and when it should be done, and when not. What happens when a range is released? What happens if a range is not released? What happens if a range is released more than once? And what does "controlled" imply here? In what way has `SortedRange` control over the underlaying data? What can I do and what can't I do to the underlying data as long as `SortedRange` has control? My failure to understand this function makes me fear I don't understand `SortedRange` at all, and thereby don't understand how to use `algorithm.sorting` properly. Thanks! -- Bastiaan.
Re: Range Error
On Sunday, 11 April 2021 at 19:45:30 UTC, Ruby The Roobster wrote: What am I doing wrong here? Is it the 'for' loop? Yes, there is a `7` where there should be an `i` on this line: ```d for(int i=7;7>=0;i--) ``` This will go on forever, so you get a range error as soon as `i < 0`. —Bastiaan.
Re: Example for Mir-Random fails
On Saturday, 3 April 2021 at 19:02:34 UTC, Brad wrote: I just do not know enough about the D libraries to figure out what is wrong. I know it is a case of type mismatch. The example appears on the Mir-Random page as listed under DUB: https://code.dlang.org/packages/mir-random [...] I think you are seeing conflicts between Phobos and Mir: they both provide unpredictableSeed and Random. If you want to use the ones from Mir, be sure to not import std or std.random, or use fully qualified names. — Bastiaan.
Re: C++/D class interop example crashes
On Saturday, 27 March 2021 at 15:09:20 UTC, Jan wrote: I just tried to get this example to work: https://dlang.org/spec/cpp_interface.html#using_d_classes_from_cpp It kept crashing for me with a 'privileged instruction' error when the function 'bar' was executed. Finally I removed the call to writefln and voilà it finally works. So why does it fail? I assumed the standard library functions should all work. I'm compiling with "dmd -shared -m64 -debug" and link against a C++ DLL that was built with VS2019. Should the D DLL not contain everything to be self-sufficient to use it's entire runtime functionality? And if not, what other functions might be problematic? The example links objects statically. You may be experiencing additional challenges with crossing DLL boundaries. I have not yet used DLLs, but did you initialise the D runtime? — Bastiaan.
Re: Contributing CDF bindings to Deimos
On Thursday, 25 March 2021 at 04:00:33 UTC, Chris Piker wrote: As an aside, software developers at NASA Goddard have now heard of D which is nice. They were pleased to see that it was supported by gcc. (Hat tip to the GDC team) That’s cool. I’d love to see NASA on https://dlang.org/orgs-using-d.html one day. — Bastiaan.
Re: Why are enums with base type string not considered strings?
On Sunday, 14 March 2021 at 16:09:39 UTC, Imperatorn wrote:
On Sunday, 14 March 2021 at 10:42:17 UTC, wolframw wrote:
enum BoolEnum : bool { TestBool = false }
enum CharEnum : char { TestChar = 'A' }
enum StringEnum : string { TestString = "Hello" }
pragma(msg, isBoolean!BoolEnum); // true
pragma(msg, isSomeChar!CharEnum); // true
pragma(msg, isSomeString!StringEnum); // false
Why does isSomeString not return true for an enum with base
type string
May be a regression?
https://issues.dlang.org/show_bug.cgi?id=16573
Indeed: https://run.dlang.io/is/liSDBZ
It regressed in 2.079.1. Seems to be worth an issue report.
—Bastiaan.
