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 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 TypeInfo_Class or
object.TypeInfo, such as "Violin" or "StringIn
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 TypeInfo_Class or
object.TypeInfo, such as "Violin" or "StringInstrument".
Am I missing something or have I made a mistake
On Friday, 8 August 2025 at 05:19:28 UTC, monkyyy wrote:
```d
--- s.d
struct S
{
auto match(A...)=match_!A;
}
template match_(A...){
auto match_(){return 1;}
}
--- main.d
import std.sumtype;
import s;
void main()
{
S s;
assert(s.match!(_ => _) == 1);
}
```
I lik
The code looks fine.
TypeInfo is used at runtime to describe compile time constructs.
Classes require it for down casting, it is acquired from the runtime value.
For instance if the reference is null, the TypeInfo should be null as well.
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 Saturday, 9 August 2025 at 04:02:03 UTC, Brother Bill wrote:
I understand that members of various levels can be
distinguished.
What I don't understand is why one would use this technique.
I skipped that part of the question because I thought that the
fact that it's not a shadowing case inv
On Saturday, 9 August 2025 at 04:02:03 UTC, Brother Bill wrote:
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 typ
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
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
technique?
That's not considered as shadowing as you can di
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
technique?
Overload rules are probably more fundamental the
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 Friday, 8 August 2025 at 14:11:48 UTC, Brother Bill wrote:
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?
I've used it my Lua wrapper to give it a slightly more natural
interface when call
On Friday, 8 August 2025 at 14:11:48 UTC, Brother Bill wrote:
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?
Glue code, someone was fairly good about trying to hide all
implementation details
On Fri, Aug 08, 2025 at 02:11:48PM +, Brother Bill via Digitalmars-d-learn
wrote:
> What are some use cases where struct opCall would be useful?
When the struct is intended to be a function object. I.e., a type that
abstracts a function.
> As far as I know, this capability is uniqu
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 Friday, 8 August 2025 at 04:40:14 UTC, Andrey Zherikov wrote:
I have a template similar to `sumtype.match`:
```d
--- s.d
struct S {}
template match(A...)
{
auto match(S){return 1;}
}
--- main.d
//import std.sumtype; // uncomment to get error
import s;
void main()
{
S s;
asser
I have a template similar to `sumtype.match`:
```d
--- s.d
struct S {}
template match(A...)
{
auto match(S){return 1;}
}
--- main.d
//import std.sumtype; // uncomment to get error
import s;
void main()
{
S s;
assert(s.match!(_ => _) == 1);
}
```
If I uncomment `import std.symtype
On Thursday, 7 August 2025 at 17:38:41 UTC, monkyyy wrote:
On Thursday, 7 August 2025 at 17:33:07 UTC, monkyyy wrote:
Note I believe `getBargs` will break if H ever doesnt contain a
T so despite your trying to hide implementation details your
exposing them all the same
Thanks for your ans
On Thursday, 7 August 2025 at 16:58:34 UTC, Andrey Zherikov wrote:
On Wednesday, 6 August 2025 at 23:58:03 UTC, monkyyy wrote:
```d
struct A(T) {}
struct H(T) {}
alias B(T) = A!(H!T);
void f(T)(A!(H!T) b) {}
void g(T)(A!T b) {}
void h(B_)(B_ b)if(is(B_==A!(H!T),T)){}
unittest{
f(B!string.i
On Thursday, 7 August 2025 at 17:33:07 UTC, monkyyy wrote:
Note I believe `getBargs` will break if H ever doesnt contain a T
so despite your trying to hide implementation details your
exposing them all the same
On Wednesday, 6 August 2025 at 23:58:03 UTC, monkyyy wrote:
```d
struct A(T) {}
struct H(T) {}
alias B(T) = A!(H!T);
void f(T)(A!(H!T) b) {}
void g(T)(A!T b) {}
void h(B_)(B_ b)if(is(B_==A!(H!T),T)){}
unittest{
f(B!string.init);
g(B!int.init);
h(B!bool.init);
}
```
I dont think you
On Thursday, 31 July 2025 at 10:19:43 UTC, IchorDev wrote:
On Wednesday, 23 July 2025 at 14:12:30 UTC, Brian Callahan
wrote:
On Monday, 21 July 2025 at 13:29:23 UTC, Albert wrote:
[...]
I know you got things going with LDC, but I use GDC for all my
D needs on macOS. I have a tarball that's a
On Wednesday, 6 August 2025 at 22:41:28 UTC, Andrey Zherikov
wrote:
This is simplified code that illustrates the issue I've faced:
```d
struct A(T) {}
alias B(T) = A!T;
void f(T)(B!T b) {}
f(B!string.init);
// Error: template `f` is not callable using argument types
`!()(A!string)`
//f(B!str
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
This is simplified code that illustrates the issue I've faced:
```d
struct A(T) {}
alias B(T) = A!T;
void f(T)(B!T b) {}
f(B!string.init);
// Error: template `f` is not callable using argument types
`!()(A!string)`
//f(B!string.init);
// ^
// Candidate is: `f(T)(B!T b)`
//void f(T)(B!T
```D
import std;
import core.sys.posix.unistd : sleep;
void foo (size_t i)
{
writeln (i);
sleep (1);
writefln ("thread %d end", i);
}
void main (string [] args)
{
auto nthreads = args [1].to!size_t;
Tid [] threads;
foreach (i; 0 .. nthreads)
threads ~= spawn (&foo, i);
On Tuesday, August 5, 2025 6:42:43 PM Mountain Daylight Time Brother Bill via
Digitalmars-d-learn wrote:
> 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.
D structs don'
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;
void incrementBy(int increment, int preCount = this.count)
Doesn't look like it: https://dlang.org/spec/function.html#postconditions
Unfortunately Walter isn't very keen on contracts in general now days
and may not be willing to accept any DIP's for this.
If you want it improved, you will likely have to implement it, on top of
the DIP itself.
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 Wed, Aug 06, 2025 at 12:42:43AM +, Brother Bill via Digitalmars-d-learn
wrote:
> 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.
This is incorrect.
T
--
The A
`@disable this(this);`
On Wednesday, 6 August 2025 at 00:42:43 UTC, Brother Bill wrote:
If a struct has a user provided constructor, then the default
constructor is removed.
Is it?
```d
struct S
{
int i;
this(int);
}
void main()
{
S s = S(); // OK
}
```
On Wednesday, 6 August 2025 at 00:42:43 UTC, Brother Bill wrote:
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?
it always seemed like a
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?
On Tue, Aug 05, 2025 at 03:27:06AM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Monday, August 4, 2025 5:21:53 PM Mountain Daylight Time H. S. Teoh via
> Digitalmars-d-learn wrote:
> > Fast forward 20 or so years, and things have changed a bit. People
> > sta
On Tuesday, 5 August 2025 at 14:19:16 UTC, IchorDev wrote:
On Thursday, 31 July 2025 at 14:44:21 UTC, monkyyy wrote:
On Thursday, 31 July 2025 at 11:29:41 UTC, IchorDev wrote:
I'd much prefer if the above code worked rather than having
to do this:
```d
static foreach(i; 0..a.tupleof.length){
On Thursday, 31 July 2025 at 14:44:21 UTC, monkyyy wrote:
On Thursday, 31 July 2025 at 11:29:41 UTC, IchorDev wrote:
I'd much prefer if the above code worked rather than having to
do this:
```d
static foreach(i; 0..a.tupleof.length){
pragma(msg, __traits(getAttributes, a.tupleof[i]));
//Alias
On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:
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 i
On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:
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.
This is both one of the strong and weak points of D:
On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:
I am in my learning curve for D as an experienced developer.
[...]
Should D be considered a language that should be learned in its
entirety?
Or should most developers stick to the "Safe D" subset?
I think what you should get is th
On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:
Every language has its "nits", even Eiffel. The concern is
whether that is a straight forward approach to get things done,
avoid the "dragons", and work with existing libraries without
needing a "wizard" to cast some spells.
Shou
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
On Monday, August 4, 2025 2:02:48 PM Mountain Daylight Time Brother Bill via
Digitalmars-d-learn wrote:
> 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 se
On Monday, August 4, 2025 5:21:53 PM Mountain Daylight Time H. S. Teoh via
Digitalmars-d-learn wrote:
> Fast forward 20 or so years, and things have changed a bit. People
> started using structs for many other things, some beyond the original
> design, and inevitably ran into cases w
On Mon, Aug 04, 2025 at 08:02:48PM +, Brother Bill via Digitalmars-d-learn
wrote:
> I feel like I am going into the hornet's nest with this discussion.
You are. ;-)
> I have created a struct with some members, and want to have a
> parameterless constructor that sets the me
On Monday, 4 August 2025 at 20:02:48 UTC, Brother Bill wrote:
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
On Monday, 4 August 2025 at 20:02:48 UTC, Brother Bill wrote:
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 know of no sane way to do that
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.
On Monday, 4 August 2025 at 15:13:19 UTC, Nick Treleaven wrote:
To complicate matters, the spec sometimes uses 'object' just to
mean an instance of any type:
If a pointer contains a null value, it is not pointing to a
valid object.
https://dlang.org/spec/type.html#pointers
Note: git blame h
On Monday, 4 August 2025 at 02:47:47 UTC, Jonathan M Davis wrote:
The spec does use the term "aggregate type" to refer to
classes, structs, interfaces, and unions, since they're all
aggregates of values. However, from what I've seen, the term
isn't used very often outside of the spec, and I don
On Monday, 4 August 2025 at 02:03:35 UTC, Jonathan M Davis wrote:
I don't think that I've ever seen anyone claiming before that a
an instance of a struct should not be considered an object.
Calling a plain old data like a vec2 an "object" is projecting
and shouldnt be done.
---
The terminol
On Sunday, August 3, 2025 9:31:34 AM Mountain Daylight Time Paul Backus via
Digitalmars-d-learn wrote:
> I have never seen any D programmer use "object" to mean "struct
> or class instance."
That is always how I use the term. I see no reason to differentiate between
wh
On Sunday, 3 August 2025 at 15:31:34 UTC, Paul Backus wrote:
The second one comes from C, where "object" refers to any value
stored in memory. This kind of "object" is defined in the
["Object Model" section][2] of the language specification, and
is mostly of interest to those writing low-lev
On Sunday, August 3, 2025 5:29:46 AM Mountain Daylight Time Mike Parker via
Digitalmars-d-learn wrote:
> Classes and structs in C++ are both value types, and instances of
> both are referred to as objects. This isn't unusual.
>
> An object is a concrete instance of a type des
On Sunday, 3 August 2025 at 11:11:43 UTC, Brother Bill wrote:
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
On Sunday, 3 August 2025 at 11:11:43 UTC, Brother Bill wrote:
Please assist with my "deprogramming" from "objects" being only
for reference types.
the words mean nothing, it was all compounding mistakes that then
people exploited to sell books
https://www.amazon.com/Object-Oriented-Programmi
On Sunday, 3 August 2025 at 11:11:43 UTC, Brother Bill wrote:
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
On 03/08/2025 11:11 PM, Brother Bill wrote:
Am curious whether experienced D developers actually refer to both
struct and class variables as "objects" without confusion.
Strictly speaking the definition from the C standard:
"region of data storage in the execution environment, the contents of
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
On Saturday, 2 August 2025 at 20:29:22 UTC, Brother Bill wrote:
Why does this run, but not display expected null reference
exception?
Death by signal (SIGSEGV in this case) is not an Exception. I
had a program dying from a SIGPIPE--same deal, you can't catch it
with an exception handler.
F
It does die from the segfault.
Program terminated with signal: SIGSEGV
Note: by default D does not throw an exception (it would be an Error not
Exception).
There is some code to do this for linux, and we've approved if someone
is willing to implement it, a read barrier to check for null dere
On Saturday, 2 August 2025 at 20:29:22 UTC, Brother Bill wrote:
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("
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
On Monday, 28 July 2025 at 12:25:39 UTC, kinke wrote:
then the rewrite becomes a bit more complex:
```d
int __result; // magic variable inserted by the compiler, for
the main() return value
const __opApplyResult = ints.opApply((ref int item) {
if (item == 0) {
__result = item; // set re
On Monday, 28 July 2025 at 19:28:54 UTC, Mike Shah wrote:
On Monday, 28 July 2025 at 18:57:27 UTC, kinke wrote:
On Monday, 28 July 2025 at 14:28:57 UTC, Mike Shah wrote:
Is there somewhere already in LDC2 where I can dump out the
generated transformation (Otherwise I can probably read the
IR w
On Thursday, 31 July 2025 at 11:29:41 UTC, IchorDev wrote:
I'd much prefer if the above code worked rather than having to
do this:
```d
static foreach(i; 0..a.tupleof.length){
pragma(msg, __traits(getAttributes, a.tupleof[i]));
//AliasSeq!(y(10))
}
```
That verbosity is unnecessary to swap
How come doing a `foreach` on `.tupleof` causes `
__traits(getAttributes` to return nothing? Is it because it
creates a new 'symbol'? Is this a bug?
```d
struct y{
int z;
}
struct X{
@y(z: 10) string x;
}
void main(){
X a;
foreach(b; a.tupleof){
On Monday, 21 July 2025 at 17:21:58 UTC, Albert wrote:
Though I do think D could do so much better with onboarding
first time users...
I think it's not entirely fair to say that, given that your issue
was mostly that (1) you downloaded a compiler that doesn't fully
support your native CPU arc
On Wednesday, 23 July 2025 at 14:12:30 UTC, Brian Callahan wrote:
On Monday, 21 July 2025 at 13:29:23 UTC, Albert wrote:
Hi all,
I am completely new to D, wished to try it out and write a
small app in it. However, for the last couple hours I am ready
to pull my hair out as I have no idea how
On Wednesday, 30 July 2025 at 20:03:37 UTC, 0xEAB wrote:
On Wednesday, 30 July 2025 at 19:45:20 UTC, Andy Valencia wrote:
but I'd like to understand what's up before just changing my
code to assume 0 is a success value?
AFAICT your code is wrong.
The parameters of `fread()` are `ptr`, `size`,
On 7/30/25 12:45 PM, Andy Valencia wrote:
> Scratching my head here. fread()
I haven't used anything other than rawRead() for that purpose. rawRead()
returns a slice of what it's just read:
import std.algorithm;
import std.exception;
import std.file;
import std.format;
import std.stdio;
void
On Wednesday, 30 July 2025 at 19:45:20 UTC, Andy Valencia wrote:
but I'd like to understand what's up before just changing my
code to assume 0 is a success value?
AFAICT your code is wrong.
The parameters of `fread()` are `ptr`, `size`, `n`, `stream`.
Your code is attempting to read `1` unit wi
On Wednesday, 30 July 2025 at 19:45:20 UTC, Andy Valencia wrote:
Scratching my head here. fread() really appears to be the
standard C idea of an fread(), so it returns a count. Instead,
it returns 0. The buf[] does indeed have the expected content,
but I'd like to understand what's up before
Scratching my head here. fread() really appears to be the
standard C idea of an fread(), so it returns a count. Instead,
it returns 0. The buf[] does indeed have the expected content,
but I'd like to understand what's up before just changing my code
to assume 0 is a success value?
(Linux,
On Wednesday, 30 July 2025 at 18:00:39 UTC, H. S. Teoh wrote:
On Wed, Jul 30, 2025 at 10:54:15AM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote: [...]
immutable int[] i;
shared static this()
{
immutable(int)[] temp;
temp ~= foo();
temp ~= bar();
i = temp;
}
But even the
On Wed, Jul 30, 2025 at 10:54:15AM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> immutable int[] i;
>
> shared static this()
> {
> immutable(int)[] temp;
> temp ~= foo();
> temp ~= bar();
> i = temp;
> }
>
> But even the shared
On Tuesday, July 29, 2025 5:18:18 PM Mountain Daylight Time Brother Bill via
Digitalmars-d-learn wrote:
> Your changes do work, but at the cost of making i NOT deeply
> immutable: no assignment, no changing any elements, no appending,
> no setting length. This syntax permits appe
On Tuesday, 29 July 2025 at 23:48:58 UTC, H. S. Teoh wrote:
`i` is immutable, so it's illegal to use mutating operations
like ~= on it.
@luna
The question should be if programming in d (page 177
https://ddili.org/ders/d.en/Programming_in_D.pdf) should be
authoritive here
It is possible t
On Tue, Jul 29, 2025 at 10:57:50PM +, Brother Bill via Digitalmars-d-learn
wrote:
> ```
> import std.stdio;
>
> immutable int[] i;
>
> shared static this() {
> writeln("In shared static this()");
> i ~= 43;
> }
`i` is immutable, so it'
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()");
writeln("i: ", i);
}
```
Error messages:
C:\D\dmd2\w
On Tuesday, 29 July 2025 at 23:18:18 UTC, Brother Bill wrote:
Your changes do work, but at the cost of making i NOT deeply
immutable: no assignment, no changing any elements, no
appending, no setting length.
if you insit on the type id suggest this code then
```d
import std.stdio;
immutabl
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()");
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()");
writeln("i: ", i);
}
```
Error messages:
C:\D\dmd2\w
```
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
On Tuesday, 29 July 2025 at 21:47:05 UTC, not monkyyy wrote:
Who are you?
On Tuesday, 29 July 2025 at 20:34:27 UTC, Nick Treleaven wrote:
On Monday, 28 July 2025 at 18:51:23 UTC, monkyyy wrote:
On Monday, 28 July 2025 at 11:18:48 UTC, Nick Treleaven wrote:
The solution I offered at the time while still fundamentally
flawed was far more robust then what was merged
W
On Monday, 28 July 2025 at 18:51:23 UTC, monkyyy wrote:
The solution I offered at the time while still fundamentally
flawed was far more robust
Sounds a lot like…
Whack-a-moleing
On Monday, 28 July 2025 at 18:51:23 UTC, monkyyy wrote:
On Monday, 28 July 2025 at 11:18:48 UTC, Nick Treleaven wrote:
The solution I offered at the time while still fundamentally
flawed was far more robust then what was merged
What solution?
On Monday, 28 July 2025 at 18:02:45 UTC, H. S. Teoh wrote:
On Sun, Jul 27, 2025 at 05:02:35PM +, user1234 via
Digitalmars-d-learn wrote: [...]
Simply because because if OP writes
```
class Person{
string name;
this(string name){this.name=name;}
}
class Someone:Person{
}
void main
still want this:
https://forum.dlang.org/thread/lmvyzfatklcvrijcy...@forum.dlang.org
I dont think it will magicly appear in a few hours but maybe
someone wants to write the templated opApply code
some active code:
```d
auto takewhilecmp(string op="<",R,T)(R r,ref T senti){
struct ran
On Monday, 28 July 2025 at 18:57:27 UTC, kinke wrote:
On Monday, 28 July 2025 at 14:28:57 UTC, Mike Shah wrote:
Is there somewhere already in LDC2 where I can dump out the
generated transformation (Otherwise I can probably read the IR
well enough)?
Yeah I'm afraid the IR is probably the best
On Monday, 28 July 2025 at 14:28:57 UTC, Mike Shah wrote:
Is there somewhere already in LDC2 where I can dump out the
generated transformation (Otherwise I can probably read the IR
well enough)?
Yeah I'm afraid the IR is probably the best source. LDC's `-vv`
verbose codegen output would show
On Monday, 28 July 2025 at 11:18:48 UTC, Nick Treleaven wrote:
In Phobos 3 `isCallable` will likely be replaced. I think when
it was made to support some templates with `!()`, that muddied
the waters.
Whack-a-moleing; you guys do that allot
The solution I offered at the time while still fun
On Sun, Jul 27, 2025 at 05:02:35PM +, user1234 via Digitalmars-d-learn
wrote:
[...]
> Simply because because if OP writes
>
> ```
> class Person{
> string name;
> this(string name){this.name=name;}
> }
> class Someone:Person{
> }
> void main(){
&g
On Monday, 28 July 2025 at 12:25:39 UTC, kinke wrote:
On Monday, 28 July 2025 at 04:39:00 UTC, Mike Shah wrote:
[...]
I think that's where the confusion comes from, that misleading
`-vcg-ast` output for the loop-body-lambda, apparently printed
as `… => 0` regardless of the actual loop body.
On Monday, 28 July 2025 at 11:06:40 UTC, kinke wrote:
On Sunday, 27 July 2025 at 23:23:40 UTC, user1234 wrote:
That is confusing
It affects the mangling of global vars, just like functions.
ah indeed
On Monday, 28 July 2025 at 04:39:00 UTC, Mike Shah wrote:
**So really my one concrete question is** -- can I see
main.main()__foreachbody_L21_C3(ref int) anywhere?
I think that's where the confusion comes from, that misleading
`-vcg-ast` output for the loop-body-lambda, apparently printed as
1 - 100 of 2289 matches
Mail list logo
