On Monday, 22 January 2024 at 17:15:55 UTC, bachmeier wrote:
I get incorrect results, and when I'm lucky, my program
segfaults because I accessed something I shouldn't. When I'm
not, it silently and happily gives me the wrong answer.
Maybe a compiler warning (not error) would help with detecti
On Monday, 22 January 2024 at 21:11:17 UTC, NonNull wrote:
I'd like SumType to combine the implicit tags so there's only
one tag.
SumType does not do this automatically (because sometimes you
might want to keep the inner SumTypes separate), but you can do
it yourself like this:
alias
On Monday, 22 January 2024 at 16:35:39 UTC, ryuukk_ wrote:
On Monday, 22 January 2024 at 16:16:56 UTC, NonNull wrote:
I am defining a new value type (small struct) from some old
value types that are already `SumType`s.
So I want to have some `SumType`s as some of the alternative
types in anot
On Monday, 22 January 2024 at 01:14:06 UTC, Steven Schveighoffer
wrote:
On Sunday, 21 January 2024 at 16:05:40 UTC, Gavin Gray wrote:
The following code:
ulong charlie = 11;
long johnstone = std.algorithm.comparison.max(0, -charlie);
writeln(format!"johnstone %s"(johnstone));
Results in
On Monday, 22 January 2024 at 16:39:10 UTC, Nick Treleaven wrote:
Memory safety issues are a worse class of bug than arithmetic
bugs. The latter are reproducible if you feed them the same
input.
Memory safety bugs are reproducible with the tools like
`valgrind`. Whereas arithmetic overflow bu
On Monday, 22 January 2024 at 16:39:10 UTC, Nick Treleaven wrote:
I've said multiple times that it's silly to spend so much time
on memory safety if the language is going to allow stuff like
this without a simple way to prevent it.
Memory safety issues are a worse class of bug than arithmetic
On Monday, 22 January 2024 at 01:14:06 UTC, Steven Schveighoffer
wrote:
The language should not allow unary unsigned anything.
This is unlikely to get fixed, just due to the nature of D's
philosophy when it comes to C compatibility.
It would also break a lot of existing code.
I think the b
On Monday, 22 January 2024 at 16:16:56 UTC, NonNull wrote:
I am defining a new value type (small struct) from some old
value types that are already `SumType`s.
So I want to have some `SumType`s as some of the alternative
types in another `SumType`.
How how efficient this is, including space
I am defining a new value type (small struct) from some old value
types that are already `SumType`s.
So I want to have some `SumType`s as some of the alternative
types in another `SumType`.
How how efficient this is, including space efficient?
On Monday, 22 January 2024 at 15:56:59 UTC, zjh wrote:
On Monday, 22 January 2024 at 15:51:37 UTC, zjh wrote:
I spent `too much time` on D.
And some of the inherent `drawbacks` of `C++` are too hateful.
It's a package deal. Everything in C++ is there because there
were benefits when they a
On Monday, 22 January 2024 at 15:51:37 UTC, zjh wrote:
I spent `too much time` on D.
And some of the inherent `drawbacks` of `C++` are too hateful.
On Monday, 22 January 2024 at 15:47:23 UTC, bachmeier wrote:
Sounds like you should be using C++. Why are you here?
I spent `too much time` on D.
On Monday, 22 January 2024 at 15:14:32 UTC, Bkoie wrote:
D is totally different from C++ in D you usually you wont
construct the struct directly use alias as.
Stop being `unconventional` and quickly copy their `good things`.
Otherwise, the `development speed` of the D language is really
`too
On Monday, 22 January 2024 at 15:45:45 UTC, zjh wrote:
On Monday, 22 January 2024 at 15:33:01 UTC, ryuukk_ wrote:
it only took me 1 project to never want to touch C++ again..
D language used to have no `copy constructor`, isn't it now
added in again?
You have to admit the good aspects of `
On Monday, 22 January 2024 at 15:33:01 UTC, ryuukk_ wrote:
it only took me 1 project to never want to touch C++ again..
D language used to have no `copy constructor`, isn't it now added
in again?
You have to admit the good aspects of `C++`.
You should take a look at the `latest C++`. C++ ha
I should note that it only took me 1 project to never want to
touch C++ again.. that must be telling something, either about
the language, or me, or both lol
On Monday, 22 January 2024 at 11:31:11 UTC, zjh wrote:
On Monday, 22 January 2024 at 08:54:54 UTC, zjh wrote:
```d
struct Person {
string name, email;
ulong age;
}
Person a{"n","email",33};
```
C++ can achieve ultimate `simplicity` without violating `DRY`,
And here, D violates the `D
On Monday, 22 January 2024 at 11:31:11 UTC, zjh wrote:
On Monday, 22 January 2024 at 08:54:54 UTC, zjh wrote:
C++ can achieve ultimate `simplicity` without violating `DRY`,
And here, D violates the `DRY` principle!
Moreover, as the `package level, module level, class level,
member level`, D lang
On Monday, 22 January 2024 at 08:54:54 UTC, zjh wrote:
```d
struct Person {
string name, email;
ulong age;
}
Person a{"n","email",33};
```
C++ can achieve ultimate `simplicity` without violating `DRY`,
And here, D violates the `DRY` principle!
Moreover, as the `package level, module l
On Monday, 22 January 2024 at 06:43:17 UTC, thinkunix wrote:
Gavin Gray via Digitalmars-d-learn wrote:
The following code:
ulong charlie = 11;
long johnstone = std.algorithm.comparison.max(0, -charlie);
writeln(format!"johnstone %s"(johnstone));
Results in (without any warning(s)):
jo
On Monday, 22 January 2024 at 11:31:11 UTC, zjh wrote:
D language violates integrity.
Because D has no `class level` limit.
These are all not `serious states`.
It seems that D language is not `professional`.
Dear D-gurus,
being new to D I am trying my first steps and the language is
quite intuitive and appealing.
When reading a file and creating a hash for the reocrds I want to
get only the most recent ones. For this I need to convert
Date/Time-Strings to comparable DateTime-Objects.
The code belo
On Monday, 22 January 2024 at 08:54:54 UTC, zjh wrote:
On Monday, 22 January 2024 at 08:27:36 UTC, Joel wrote:
```d
import std;
struct Person {
string name, email;
ulong age;
auto withName(string name) { this.name=name; return this; }
auto withEmail(string email) { this.email=e
On Monday, 22 January 2024 at 08:54:54 UTC, zjh wrote:
VS:`C++`
```d
struct Person {
string name, email;
ulong age;
}
Person a{"n","email",33};
```
It's not much different in D. ;)
```d
import std;
struct Person {
string name, email;
ulong age;
}
void main() {
auto p = P
On Monday, 22 January 2024 at 08:54:21 UTC, Danilo wrote:
It's common OOP style in some frameworks.
With latest D you can also just use named parameters:
```d
import std;
struct Person {
/*private*/ string name, email;
/*private*/ ulong age;
}
void main() {
auto p = Person(
On Monday, 22 January 2024 at 08:54:54 UTC, zjh wrote:
On Monday, 22 January 2024 at 08:27:36 UTC, Joel wrote:
```d
import std;
struct Person {
string name, email;
ulong age;
auto withName(string name) { this.name=name; return this; }
auto withEmail(string email) { this.email=e
On Monday, 22 January 2024 at 08:27:36 UTC, Joel wrote:
```d
import std;
struct Person {
string name, email;
ulong age;
auto withName(string name) { this.name=name; return this; }
auto withEmail(string email) { this.email=email; return
this; }
auto withAge(ulong age) { thi
On Monday, 22 January 2024 at 08:35:01 UTC, Joel wrote:
I've lost interest in the video, looks like horrible syntax
(F#).
Nonetheless, this usually used with Objects (new class/struct
instances), like so:
```d
import std;
struct Person {
string name, email;
ulong age;
auto withNa
On Monday, 22 January 2024 at 08:27:36 UTC, Joel wrote:
I've been watching a video (YouTube - "Pipeline-oriented
programming - Scott Wlaschin - NDC Porto 2023") with something
like the following code. This only sets the first method call,
so I'm wanting to know how to make this work, for the
s
I've been watching a video (YouTube - "Pipeline-oriented
programming - Scott Wlaschin - NDC Porto 2023") with something
like the following code. This only sets the first method call, so
I'm wanting to know how to make this work, for the subsequent
methods.
```d
import std;
struct Person {
30 matches
Mail list logo
