In "The D Programming Language", page 402, the toy program fails.
The first fail is that enforce() needs: import std.exception;
The second fail is that when debugging, in Visual Studio 2015
Community Edition,
it fails with this error:
First-change exception: std.format.FormatException Unterm
On Sunday, 14 February 2016 at 23:39:33 UTC, cym13 wrote:
On Sunday, 14 February 2016 at 22:54:36 UTC, Brother Bill wrote:
In "The D Programming Language", page 402, the toy program
fails.
[...]
Can't reproduce with DMD 2.0.70, LDC 0.16.1 or GDC 5.3.0 on
Linux x86_64. The code seems to work
On Thursday, 24 July 2025 at 17:19:17 UTC, Andy Valencia wrote:
What is considered the "clean" way to address this error:
```
tst60.d(7): Error: class `tst60.B` cannot implicitly generate a
default constructor when base class `tst60.A` is missing a
default constructor
```
Yes, this is a toy
In Eiffel, it is trivial to get a report for Subject Matter
Experts (SMEs) that will provide feedback that the DbC contracts
are what they agreed to.
It would be nice to have this in D.
Does D already have this, or should this be added to DIP Ideas
forum?
Imagine a sample contract for Vats
From "Programming in D" book:
import std.stdio;
import std.random;
void main() {
int number = uniform(1, 101);
writeln("Edit source/app.d to start your project.");
}
Running it generates:
phobos64.lib(random_6ea_855.obj) : error LNK2019: unresolved
external sym
On Saturday, 26 July 2025 at 17:48:43 UTC, Monkyyy wrote:
On Friday, 25 July 2025 at 21:27:55 UTC, Brother Bill wrote:
On Friday, 25 July 2025 at 18:47:19 UTC, Ali Çehreli wrote:
On 7/25/25 4:10 AM, Brother Bill wrote:
> On Friday, 25 July 2025 at 10:56:08 UTC, novicetoo wrote:
>> check https:/
On Friday, 25 July 2025 at 10:56:08 UTC, novicetoo wrote:
check https://ddili.org/ders/d.en/index.html
under "Code samples as a .zip file"
Checked that out. These are not in order, nor exhaustive.
I'll create my own code samples, then post them here first.
On Friday, 25 July 2025 at 07:16:55 UTC, evilrat wrote:
On Friday, 25 July 2025 at 01:04:31 UTC, Brother Bill wrote:
From "Programming in D" book:
import std.stdio;
import std.random;
void main() {
int number = uniform(1, 101);
writeln("Edit source/app.d to start your proj
Has anyone already published the D examples from the "Programming
in D" book?
If not, I'll do it, and publish it here first.
It would be good to have this on dlang.org for D newbies.
On Friday, 25 July 2025 at 03:57:34 UTC, Andy Valencia wrote:
On Friday, 25 July 2025 at 02:40:35 UTC, H. S. Teoh wrote:
In D, constructors are not inherited, so yes, unfortunately
you have to write a forwarding ctor that passes the arguments
along to the base class.
My OO worldview goes bac
On Friday, 25 July 2025 at 18:47:19 UTC, Ali Çehreli wrote:
On 7/25/25 4:10 AM, Brother Bill wrote:
> On Friday, 25 July 2025 at 10:56:08 UTC, novicetoo wrote:
>> check https://ddili.org/ders/d.en/index.html
>> under "Code samples as a .zip file"
>
> Checked that out. These are not in order, nor
In Programming in D book, page 247, it is written: Variables of
struct and class types are called objects.
This struck me as odd and confusing. I have always been taught
that objects are instances of classes. That is, new MyClass
creates an instance or object of MyClass.
There was a wall
From page 233 of "Programming in D".
```
import std.stdio;
import std.exception;
void main() {
MyClass variable;
use(variable);
}
class MyClass {
int member;
}
void use(MyClass variable) {
writeln("variable: ", variable);
try {
wr
I feel like I am going into the hornet's nest with this
discussion.
I have created a struct with some members, and want to have a
parameterless constructor that sets the member values at run time.
I have seen things like @disable this(); and static opCall(),
but don't quite understand them.
I am in my learning curve for D as an experienced developer.
What has attracted me to D is the combination of features:
Design by Contract, Functional Programming, OOP, and more.
But I have been exploring the "weeds" and am curious if D is only
for rocket scientists or for regular programmers, i
It doesn't seem like modern D needs the @disable feature.
If a struct has a user provided constructor, then the default
constructor is removed.
Are there any cases where @disable is useful in modern D?
Lets say we have the member function incrementBy(int increment)
```
struct Counter {
int count;
void incrementBy(int increment)
in {
assert(increment >= 0, "increment must be zero or greater");
}
out {
// want to state assert(count == old(count) + increment);
}
d
On Tuesday, 29 July 2025 at 23:03:41 UTC, monkyyy wrote:
On Tuesday, 29 July 2025 at 22:57:50 UTC, Brother Bill wrote:
```
import std.stdio;
immutable int[] i;
shared static this() {
writeln("In shared static this()");
i ~= 43;
}
void main()
{
writeln("In main()");
```
import std.stdio;
immutable int[] i;
shared static this() {
writeln("In shared static this()");
i ~= 43;
}
void main()
{
writeln("In main()");
writeln("i: ", i);
}
```
Error messages:
C:\D\dmd2\windows\bin64\..\..\src\druntime\import\core\internal\array\appe
From page 375 of Programming in D.
```
import std.stdio;
void main() {
do_something;
}
deprecated("Please use doSomething() instead.") // No
trailing semicolon, please
alias do_something = doSomething;
// void do_something() {
// writeln("Using Eiffel snake_case, which doesn't pas
On Monday, 11 August 2025 at 22:26:01 UTC, 0xEAB wrote:
On Monday, 11 August 2025 at 20:45:28 UTC, Brother Bill wrote:
```
dub build -dw
or
dub build -de
```
Also, these commands probably don’t do what you think they do.
```
-d --debug=VALUE Define the specified `debug` version
identi
On Wednesday, 6 August 2025 at 16:19:17 UTC, Nick Treleaven wrote:
On Wednesday, 6 August 2025 at 15:43:01 UTC, Brother Bill wrote:
How is this done in D?
I thought the following would work, but the compiler doesn't
like `this.count` as a default argument:
```d
struct Counter {
int count
Page 462 of Programming in D book.
The goal is to only run debug(binarySearch), and not regular
debug.
Looking for the CLI for dub or dmd.
Tried:
dmd source/app.d -w -debug=binarySearch
but it printed all the debug statements.
What CLI command will get the job done?
```
import std.stdio;
v
On Sunday, 17 August 2025 at 14:17:42 UTC, 0xEAB wrote:
On Sunday, 17 August 2025 at 14:15:37 UTC, 0xEAB wrote:
Unless you provide `-debug` as well, you should not get
identifier-less ones compiled in as well.
```
import std.stdio;
void main() {
writeln("foo");
debug writeln("bar");
Page 462 of book: Programming in D
This won't compile. Is this obsolete?
```
app.d(8,8): Error: identifier expected inside `debug(...)`, not
`1`
debug(1) writeln("entered myFunction");
^
source\app.d(10,8): Error: identifier expected inside
`debug(...)`, not `2`
debug(2) {
Page 496 of Programming in D
Going in circles. Please correct so it compiles and works.
An explanation would be helpful also.
Error Message
```
c:\dev\D\71 - 80\c73_2d_School_Student_Teacher\source\app.d(23):
Error: cannot implicitly convert expression
`this.students[cast(ulong)i]` of type `c
On Saturday, 16 August 2025 at 15:44:45 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 17/08/2025 3:44 AM, Brother Bill wrote:
On Saturday, 16 August 2025 at 15:30:43 UTC, H. S. Teoh wrote:
On Sat, Aug 16, 2025 at 03:24:55PM +, Brother Bill via
Digitalmars-d-learn wrote: [...]
So a good
On Monday, 18 August 2025 at 17:58:54 UTC, Dejan Lekic wrote:
So, to fix your error, you can remove the "const" method
qualifier from opApply, or cast the const away from the member
when you use it.
Thanks for the tip. It just needed more 'const' keywords
sprinkled in here and there.
Here
On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:
D language supports shadowing members, where the shadowed
member has same name and different type or same type.
Why is this enabled, and when should one use this advanced
technique?
D language supports shadowing members, where the shadowed member
has same name and different type on same type.
Why is this enabled, and when should one use this advanced
technique?
On page 344 of "Programming in D", we have this snippet:
```
TypeInfo_Class info = a.classinfo;
string runtimeTypeName = info.name;
```
I've expanded it to source/app.d which when runs produces output:
```
app.Violin
app.Guitar
app.Violin
TypeInfo_Class
object.TypeInfo
```
I was expecting som
On Sunday, 10 August 2025 at 10:07:13 UTC, user1234 wrote:
On Sunday, 10 August 2025 at 09:58:50 UTC, user1234 wrote:
On Saturday, 9 August 2025 at 11:13:42 UTC, Brother Bill wrote:
On page 344 of "Programming in D", we have this snippet:
[...]
I was expecting something more concrete than TypeI
On page 549 of Programming in D, it appears that D supports
'escaping' local variables to the heap, when returning their
address.
This is similar to Go.
Is this what is actually going on?
Is this 'safe' to do?
```
&result: AC067AF730
&result: AC067AF730
ptrSum : AC067AF7B0 (2 + 3)
sum: (4
On Sunday, 24 August 2025 at 15:29:01 UTC, Steven Schveighoffer
wrote:
I don't know what's happening here, but it seems like a bug.
This should not compile (it does for me, despite the comment
above).
-Steve
It does compile. I didn't change the comment from earlier code.
The core question
On page 530 of Programming in D, we have this code snippet:
```
class C {
void opCall() {
writeln("C.opCall called.");
}
}
// ...
auto o = new C();
caller!o();
caller!({ writeln("Function literal called."); })();
```
Converted this to source/app.d
```
import std.stdio;
void main() {
On Saturday, 23 August 2025 at 13:42:52 UTC, Nick Treleaven wrote:
On Saturday, 23 August 2025 at 13:38:27 UTC, Nick Treleaven
wrote:
I'm not aware of any template function called `caller` -
perhaps it is defined in the book somewhere?
```d
void caller(alias func)() {
write("calling: ");
On Sunday, 24 August 2025 at 17:30:33 UTC, Ali Çehreli wrote:
In this case, you used the body of a 'ref' function but
compiled it as 'auto ref'. Please remove 'auto' above.
Ali
The book has 'auto ref' in "auto ref functions" section.
Does your book need a change?
I'm not sure why we should re
On Sunday, 24 August 2025 at 17:30:33 UTC, Ali Çehreli wrote:
First, thank you for reading the book and raising so many
issues. Very much appreciated!
Ali
Ali, may I have a Yes or No on permission to use your Programming
in D examples that I am expanding for a commercial Udemy course
that
What are some use cases where struct opCall would be useful?
As far as I know, this capability is unique to D. Do any other
languages support this?
On Saturday, 9 August 2025 at 01:33:03 UTC, user1234 wrote:
On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:
D language supports shadowing members, where the shadowed
member has same name and different type on same type.
Why is this enabled, and when should one use this advanced
It is obvious that reading or writing to invalid memory can
result in "undefined behavior".
But is merely pointing to invalid memory "harmful"?
The documentation states that going one past the last element of
a slice is acceptable.
But is it also safe to go 10, 100 or 1000 items past the last
On Saturday, 16 August 2025 at 23:42:04 UTC, 0xEAB wrote:
On Saturday, 16 August 2025 at 15:44:45 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Source: Programming in D book, page 432, chapter 68.8
Quote: It is valid to point at the imaginary element one past
the end of an array.
That is not
On Sunday, 17 August 2025 at 01:44:38 UTC, Monkyyy wrote:
On Sunday, 17 August 2025 at 01:19:41 UTC, Brother Bill wrote:
Merely pointing to an invalid address will not produce UB
(undefined behavior)
I linked you to the gc #wontfix list, it's explicitly the magic
words "UB".
Idk what's actu
On Saturday, 16 August 2025 at 14:43:25 UTC, H. S. Teoh wrote:
On Sat, Aug 16, 2025 at 11:56:43AM +, Brother Bill via
Digitalmars-d-learn wrote:
It is obvious that reading or writing to invalid memory can
result in
"undefined behavior".
But is merely pointing to invalid memor
On Saturday, 16 August 2025 at 15:14:21 UTC, H. S. Teoh wrote:
On Sat, Aug 16, 2025 at 03:03:21PM +, Brother Bill via
Digitalmars-d-learn wrote: [...]
I'm not sure we are on the same page.
My question is whether having a pointer to invalid memory
causes
problems. I am fully aware
On Saturday, 16 August 2025 at 15:30:43 UTC, H. S. Teoh wrote:
On Sat, Aug 16, 2025 at 03:24:55PM +, Brother Bill via
Digitalmars-d-learn wrote: [...]
So a good D developer should not store an invalid pointer
address into a pointer, with the single exception of storing a
pointer address
On Tuesday, 19 August 2025 at 20:40:47 UTC, monkyyy wrote:
On Tuesday, 19 August 2025 at 20:38:52 UTC, Brother Bill wrote:
If change 'finally' to 'finally1' in both places, it compiles
and runs.
Why does 'finally' break compilation?
Is this a BUG or a FEATURE?
[...]
its a try-catch keyword
If change 'finally' to 'finally1' in both places, it compiles and
runs.
Why does 'finally' break compilation?
Is this a BUG or a FEATURE?
From: Programming in D book, page 511.
Error:
```
c:\dev\D\71 -
80\c76_1c_c_style_code_not_needed_in_D\source\app.d(12): Error:
identifier expected followi
Two assert statements on lines 43 and 44 fail.
Should these assert statements be correct, and if so, what
changes to make them correct.
Or are they incorrect, and should be removed?
Or have I made a mistake in implementing this exercise solution?
Console output
```
areas:[TriangularArea (1, 2)
On Sunday, 31 August 2025 at 01:27:57 UTC, Steven Schveighoffer
wrote:
Why would your second iteration make a difference? Purely by
chance! In fact, on my machine, it does not exit in either case.
Welcome to the wonderful world of race conditions and
multithreading!
So this was just 'bad' lu
On Thursday, 28 August 2025 at 21:51:23 UTC, monkyyy wrote:
On Thursday, 28 August 2025 at 21:33:27 UTC, Brother Bill wrote:
The 'old book' pdf seems to be the most current approach, and
it should only be about 3 years old.
Its not even close to only 3 years old, it mayve been updated
some
I have heard that there are better or at least alternative ways
to have encapsulation, polymorphism and inheritance outside of
OOP.
With OOP in D, we have full support for Single Inheritance,
including for Design by Contract (excluding 'old'). D also
supports multiple Interfaces.
What woul
It appears that D has multiple ways of determining which created
objects are subject to GC.
For class instances, new creates a new class instance, returning
a pointer to it. While "alive", other pointers may also point to
the class instance. Once no pointers are pointing to this class
insta
https://tour.dlang.org/tour/en/basics/delegates
This is so simple. What is D complaining about?
Should this also work with a Template, as shown?
```
import std.stdio;
void main()
{
// auto add(T)(T lhs, T rhs)
// {
// return lhs + rhs;
// }
int add
On Tuesday, 9 September 2025 at 00:45:00 UTC, monkyyy wrote:
On Tuesday, 9 September 2025 at 00:40:31 UTC, Brother Bill
wrote:
https://tour.dlang.org/tour/en/gems/opdispatch-opapply
This states: "Any unknown member function call to that type is
passed to opDispatch, passing the unknown member
On Monday, 8 September 2025 at 14:42:01 UTC, evilrat wrote:
probably because you have declared nested function `add` inside
`main`, this creates a delegate closure capturing `main` scope,
if you don't want that just mark `add` static.
Yep, as a nested function, this is a delegate, not a func
It works by making doSomething as a delegate.
On Monday, 8 September 2025 at 14:42:01 UTC, evilrat wrote:
probably because you have declared nested function `add` inside
`main`, this creates a delegate closure capturing `main` scope,
if you don't want that just mark `add` static.
Marking add static works.
Still don't understand why thi
On Tuesday, 9 September 2025 at 01:24:59 UTC, monkyyy wrote:
```d
import std;
struct Vector(int N,T,string fields){
static foreach(I;0..N){
mixin("T "~fields[I]~";");
}
auto opDispatch(string __s__)(){//I suggest a habit of
avoiding simple names when generating
On Tuesday, 9 September 2025 at 09:59:40 UTC, Dejan Lekic wrote:
Hopefully this slightly modified, and commented version of your
original code will
help you understand why your mixin is failing:
```d
import std.stdio;
void main() {
CallLogger!C l;
l.callA(1, 2);
l.callB("ABC");
On Friday, 12 September 2025 at 15:38:15 UTC, Monkyyy wrote:
On Friday, 12 September 2025 at 15:31:37 UTC, Brother Bill
wrote:
On Friday, 12 September 2025 at 15:24:46 UTC, Monkyyy wrote:
On Friday, 12 September 2025 at 15:20:38 UTC, Brother Bill
wrote:
Is is possible to 'disable' .init for a
Is is possible to 'disable' .init for a struct?
source/app.d
```
import std.stdio;
void main()
{
// Can still create Archive with an empty filename. We can't
have that.
auto noDefault = Archive.init;
writefln("fileName: [%s]", noDefault.fileName);
}
// adding a constructor au
I'm not clear about why 'class'es are on the 'avoid' list.
D has excellent support for Single inheritance, Interfaces,
Design by Contract (DbC), GC, etc.
I'm aware that there is a small run time cost for selecting the
right virtual method.
To reduce this cost, one must final-ize methods that
On Friday, 12 September 2025 at 21:46:51 UTC, monkyyy wrote:
On Friday, 12 September 2025 at 20:10:25 UTC, H. S. Teoh wrote:
Phobos code was legendary for being a standard library that
didn't make your head hurt when you read it. (If you've ever
tried reading the source code for Glibc, or the s
On Friday, 12 September 2025 at 15:24:46 UTC, Monkyyy wrote:
On Friday, 12 September 2025 at 15:20:38 UTC, Brother Bill
wrote:
Is is possible to 'disable' .init for a struct?
No (and honestly it's bad style to break the constructors)
Please expound on why its 'bad style' to disable construct
On Monday, 8 September 2025 at 20:10:52 UTC, Sergey wrote:
On Monday, 8 September 2025 at 19:55:20 UTC, Neto wrote:
Why isn't D production ready?
One has to ask why to choose a production language.
1. First one has to be aware that it exists.
a. See Eiffel and D
Eiffel has been in prod
The code snippet from the book is:
```
// Allocate room for 10 MyClass objects
MyClass * buffer =
cast(MyClass*)GC.calloc(
__traits(classInstanceSize, MyClass) * 10);
```
```
class MyClass
{
int a;
string name;
char c;
}
```
MyClass is defined as a simple
On Wednesday, 3 September 2025 at 03:09:45 UTC, Ali Çehreli wrote:
GC.calloc(bytesNeeded);
Again, I misled you there.
> writeln("myClasses address: ", myClasses);
>
> alias MyClassPtr = MyClass *;
That's not useful because the type MyClass is already a
reference type, implemented as
https://tour.dlang.org/tour/en/gems/opdispatch-opapply
This states: "Any unknown member function call to that type is
passed to opDispatch, passing the unknown member function's name
as a string template parameter."
So I tried that. But the compiler didn't like it.
How should I play the game
On Monday, 25 August 2025 at 12:57:01 UTC, Steven Schveighoffer
wrote:
On Monday, 25 August 2025 at 08:36:05 UTC, Nick Treleaven wrote:
On Monday, 25 August 2025 at 00:42:33 UTC, Steven
Schveighoffer wrote:
Still, the op code compiling is a bug as the return value is
not an rvalue.
-Steve
Is there a way to see expanded templates/mixins as the D compile
expands it?
This would be nice for pedagogical purposes.
Unable to compile. Please advise.
```
c:\dev\D\81 - 90\c83_e_static_foreach_fibonacci\source\app.d(8):
Error: function declaration without return type. (Note that
constructors are always named `this`)
writeln(n);
^
c:\dev\D\81 - 90\c83_e_static_foreach_fibonacci\source\app.d(8):
On Thursday, 28 August 2025 at 13:16:26 UTC, Andy Valencia wrote:
On Thursday, 28 August 2025 at 13:09:21 UTC, Brother Bill wrote:
Unable to compile. Please advise.
```
c:\dev\D\81 -
90\c83_e_static_foreach_fibonacci\source\app.d(8): Error:
function declaration without return type. (Note that
It seems like 'templates' are the 'Achilles heel' of D.
Without starting a flame war, has D gotten to the point where
ordinary mortals have difficulty coding in D with 'templates'
such as 'cycle' requiring rewrites into 'myCycle'?
Does D now require 'deep' memory into layers of history and
w
On Thursday, 28 August 2025 at 19:21:07 UTC, monkyyy wrote:
You already started it, by personally verifying the old book,
you showed several regressions. Great work btw.
Everyone, thanks for your comments.
What would you recommend to learn the current version of D
language, for a professional
On Thursday, 28 August 2025 at 21:51:23 UTC, monkyyy wrote:
On Thursday, 28 August 2025 at 21:33:27 UTC, Brother Bill wrote:
The 'old book' pdf seems to be the most current approach, and
it should only be about 3 years old.
Its not even close to only 3 years old, it mayve been updated
some
On Wednesday, 20 August 2025 at 15:33:45 UTC, monkyyy wrote:
once again dconf contains people who talk about compile speed
as if it can be slow
Compiling Hello world in D is a little bit slower that Go
language.
If line 9 of the program is commented out, it runs fine.
Otherwise lots of error messages which don't pan out for me.
I tried changing Negative.front to be const, which didn't help.
I am not quite sure what the error messages are telling me.
Thank you for your assistance!
```
C:\D\dmd2\windows\b
On Saturday, 30 August 2025 at 03:21:14 UTC, Steven Schveighoffer
wrote:
`Tid` can only send or receive shared or immutable data. This
is a long standing requirement, and it makes sense.
The thing is, this data is shared *only* when it is going
through the message system. Once it's out, you ca
A predicate (!*isDone) vs. (*isDone == false) seems to have
different behavior, where I would expect identical behavior.
What am I missing?
This program runs forever, even though isDone changes from false
to true.
```
import std.stdio;
import std.concurrency;
import core.thread;
import core.
For the modern D developer, which is the more preferred choice,
to use 'is' or '=='?
Do the Style Guidelines or other authorities prefer one to the
other for modern D coding?
Or is either equally satisfactory?
On Saturday, 30 August 2025 at 18:04:20 UTC, Steven Schveighoffer
wrote:
On Saturday, 30 August 2025 at 11:43:27 UTC, Brother Bill wrote:
I tried various code changes, none of which worked.
Kindly provide code changes to fix warnings that reflect
modern D programming.
This worked for me:
W
The idea is that multiple shared objects use a common lock.
```
import std.stdio;
void main()
{
}
class BankAccount
{
}
void transferMoney(shared BankAccount from, shared BankAccount to)
{
synchronized (from, to)← FAILS TO COMPILE. Doesn't like
comma.
{ // ← correct
On Sunday, 31 August 2025 at 01:34:18 UTC, Steven Schveighoffer
wrote:
The correct way to do this is a nested synchronized statement:
```d
synchronized(from) synchronized(to)
{
...
}
```
-Steve
This code compiles:
```
import std.stdio;
void main()
{
}
class BankAccount
{
}
void trans
If this technique is still valid, I need the code modernized so
that it works without warnings. I'm still in the D learning
curve, so I don't quite know what is being warned, and how to
clean up the mess.
I believe that the new code runs properly, but it would be nice
for it to be 'warning f
Page 119 of Programming in D
It seems odd that == null and is null have different values?
Is this a bug or feature?
If a feature, what is the meanings of == null vs. is null?
source/app.d
```
import std.stdio;
void main()
{
// value[key]
int[string] dayNumbers =
// key :
In the following from Programming in D, page 483, we use function
keyword.
I expect that the first int in
```
int function(int);
```
represents the return value.
What does the second (int) refer to?
Then there is another example with 'delegate' instead of
'function.
```
import std.stdio;
On Wednesday, 10 September 2025 at 14:25:05 UTC, IchorDev wrote:
On Wednesday, 10 September 2025 at 14:01:29 UTC, Brother Bill
wrote:
what is the meanings of == null vs. is null?
You have already asked this question [here
before](https://forum.dlang.org/thread/nvaiwzvcrahnwzior...@forum.dlang
This works:
```
import std.stdio;
void main()
{
foo();
}
void foo() {
int addMyInts(int lhs, int rhs) {
return lhs + rhs;
}
int doSomething(int delegate(int, int) doer)
{
// call passed function
return doer(
Is there any reason to pick one of these vs. another one, or are
they all equivalent?
If equivalent, it would seem that immutable appears to be the
'strongest', whereas enum has fewer keystrokes.
Is there a D 'best practice' for this?
```
const int foo1 = 42;
enum foo2 = 42;
On Tuesday, 9 September 2025 at 01:24:59 UTC, monkyyy wrote:
```
// I suggest a habit of avoiding simple names when generating
mixin code
```
Please provide an example where providing simple names causes
'trouble'.
Is it the case that GC.collect forces a typical GC cycle, and
GC.minimize does a full mark and sweep?
I am using VS Code on Windows, and would like to use standard
debugging, such as breakpoints, examining variable contents, etc.
I am unable to do so, instead adding writeln to examine the run
time.
FWIW, author Adam Freeman prefers this approach, eschewing the
debugger.
But if I wanted to us
On Wednesday, 24 September 2025 at 22:55:57 UTC, Ali Çehreli
wrote:
So, a GC.minimize translation: "I know I will not need memory
close to what I've used so far; give all your free blocks back
to the OS."
Ali
Does D do 'Generational' GC, or is it simply if there isn't
enough memory, to do a
On Monday, 29 September 2025 at 09:27:20 UTC, felixfxu wrote:
On Sunday, 28 September 2025 at 10:47:45 UTC, Brother Bill
wrote:
I am using VS Code on Windows, and would like to use standard
debugging, such as breakpoints, examining variable contents,
etc.
I am unable to do so, instead adding
95 matches
Mail list logo
