Re: Providing implicit conversion of
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 detecting the `unsigned into signed` issue, within same size types? [core.checkedint.negs](https://dlang.org/phobos/core_checkedint.html#.negs) probably doesn't help, because `unsigned into signed` is a different issue?
Re: std.sumtype nested SumTypes
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 A = SumType!(X, Y); alias B = SumType!(Z, W); alias C = SumType!(A.Types, B.Types);
Re: std.sumtype nested SumTypes
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 another `SumType`. How how efficient this is, including space efficient? Without knowing what you are doing, this sounds like a bad idea, i suggest to revise your design I'd like SumType to combine the implicit tags so there's only one tag.
Re: Providing implicit conversion of
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 (without any warning(s)): johnstone -11 However you choose to look at it, this means -11 > 0 (regardless of all arguments concerning implicit conversions, 1's and 2's complements, being efficient, etc). 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. There's a hope that OpenD may try to improve the current situation. A related discussion can be found here: https://github.com/orgs/opendlang/discussions/4 It would also break a lot of existing code. How did you estimate that it's *a lot* of existing code? As an experiment, I tried to patch Druntime and Phobos to avoid signed overflows roughly a year ago: https://github.com/ssvb/gcc/commits/gdc-ftrapv-phobos-20220209/ And there were not too many places in the code that actually needed any fixes. Additionally taking care of unsigned overflows would surely require more changes, but I doubt that they are going to be big. In most cases encountering an arithmetic overflow is unexpected and undesired, it's typically the symptom of a bug in the code. Some clever bit-tricks relying on two's complement wrap-around exist, but they are: 1) not very common 2) can be easily debugged if arithmetic overflows are trapped at runtime 3) can be easily patched up. The two's complement wraparound behavior mandated by the D language spec is a non-technical political decision, intended to make life easier for the DMD compiler developers, but ignoring the needs of the users.
Re: Providing implicit conversion of
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 bugs are a real PITA to debug. Assuming that the incorrect results are even noticed.
Re: Providing implicit conversion of
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 bugs. The required language changes are pretty small to catch arithmetic bugs relative to implementing memory safety. Ultimately, you want the compiler to help you catch bugs in any form, and I don't think someone that wants memory safety is likely to be okay with the type of bugs in this thread. But for me, arithmetic bugs are a much larger problem than memory safety. I mostly use the GC plus calls into well-tested C libraries. 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.
Re: Providing implicit conversion of
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 bigger issue is implicit conversion from unsigned to signed of the same bit size. In a future edition D could require a larger signed type in order to implicitly convert from unsigned. That would have caught the `long johnstone =` line. Also signed should never convert to unsigned, though I don't think that's happening here.
Re: std.sumtype nested SumTypes
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 efficient? Without knowing what you are doing, this sounds like a bad idea, i suggest to revise your design
std.sumtype nested SumTypes
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?
Re: Setting field of struct object
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 added it, but those benefits came with downsides. D will end up in the same place if it emulates C++.
Re: Setting field of struct object
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.
Re: Setting field of struct object
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.
Re: Setting field of struct object
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 slow`!
Re: Setting field of struct object
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 `C++`. You should take a look at the `latest C++`. C++ has already learned many advantages of `D`, but D has not made `significant progress`! As a user, `C++` is really not much different from D, and even surpasses D `in many aspects`. `RAII `, `variable parameter` template, `coroutine, concept`, `value semantics`, very easy to understand. Moreover, the `inheritance` of C++ is very enjoyable to use in many aspects. Sounds like you should be using C++. Why are you here?
Re: Setting field of struct object
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++ has already learned many advantages of `D`, but D has not made `significant progress`! As a user, `C++` is really not much different from D, and even surpasses D `in many aspects`. `RAII `, `variable parameter` template, `coroutine, concept`, `value semantics`, very easy to understand. Moreover, the `inheritance` of C++ is very enjoyable to use in many aspects.
Re: Setting field of struct object
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
Re: Setting field of struct object
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 `DRY` principle!
Moreover, as the `package level, module level, class level,
member level`, D language violates integrity.
Because D has no `class level` limit.
These are all not `serious states`.
I used to want this feature too, but i then got hit by a bug when
i reordered the fields in the struct.. i don't want to deal with
that stuff anymore
But we now have named arguments, so this feature could be make
use of it, it's similar with enums, perhaps one day this could be
revived:
https://github.com/dlang/DIPs/blob/e2ca557ab9d3e60305a37da0d5b58299e0a9de0e/DIPs/DIP1044.md
There is even a working implementation:
https://github.com/dlang/dmd/pull/14650
Re: Setting field of struct object
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 language violates integrity. Because D has no `class level` limit. These are all not `serious states`. i think D module base system is fine wished some other lang had the same you can avoid circular import ref. dry? well he can easily turn that into a generic config static factory which its look like hes trying to do. D is totally different from C++ in D you usually you wont construct the struct directly use alias as.
Re: Setting field of struct object
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 level, class level,
member level`, D language violates integrity.
Because D has no `class level` limit.
These are all not `serious states`.
Re: Providing implicit conversion of
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)): johnstone -11 However you choose to look at it, this means -11 > 0 (regardless of all arguments concerning implicit conversions, 1's and 2's complements, being efficient, etc). The language should not allow unary unsigned anything. I have no idea what your use case is for this but... WHY are you doing this?? If you declared charlie as unsigned, why would you then attempt to compare using a negative value? If you even had the possibility that charlie might be negative, why wouldn't you use a type that can accomodate the sign? I'm sure they would if the compiler had stopped and provided an error message to tell them what they were doing. Note that in this line ``` long johnstone = std.algorithm.comparison.max(0, -charlie); ``` there is no direct assignment of a negative number to an unsigned type. The comparison is carried out as ulong and then there's an implicit conversion of a ulong to long, even though that can give a very weird result. It's perfectly natural to expect that everything will be carried out as a long since that's what's specified, or that a language like D will forbid implicit conversions if they can possibly give the wrong answer. If you change the long to int, the code will no longer compile. Aside from the general statement that programmers make mistakes, D is prone to these issues because of the heavy use of auto, and because unsigned types are used for things like the length of an array.
Re: Setting field of struct object
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`.
Effective String to Date conversion?
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 below works but looks a bit clumsy. Is there a more
efficient (shorter) way to accomplish this?
Thanks in advance
```d
// Read lines using foreach.
void main( string args[])
{
auto file = File(args[1]);// Open for reading
auto range = file.byLineCopy();
auto iline=0;
int idxARE=2,idxDC=3,idxTD=0;
string [] records[string];
DateTime getDateTime( string [] row)
{
int d,m,y,ho,mi,se;
row[0].formattedRead!"%d.%d.%d"(d, m, y);
row[1].formattedRead!"%d:%d:%d"(ho, mi, se);
return DateTime(y,m,d,ho,mi,se);
}
foreach (line; range)
{
if (!line.empty)
{
string [] row = line.split(";");
string key = [row[2], row[3]].join("_"); // unique key
if(iline>0) // skip header line
{
if(key in records)
{
// do we have a newer one?
if( getDateTime(row) >
getDateTime(records[key]))
{
records[key]=row;
writeln("UPDATE:",key);
}
} else
{
// first one:
records[key]=row;
}
}
iline++;
}
}
writeln( records.length);
writeln("Lines: ",i);
}
```
Re: Setting field of struct object
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=email; return
this; }
auto withAge(ulong age) { this.age=age; return this; }
}
void main() {
Person p;
p.withName("Tom").withEmail("joel...@gmail.com").withAge(44);
writeln(p);
}
```
VS:`C++`
```d
struct Person {
string name, email;
ulong age;
}
Person a{"n","email",33};
```
D:
```d
import std.stdio;
struct Person {
string name, email;
ulong age;
}
void main() {
Person p = Person(name: "n", email: "email", age: 33);
writefln!"%s"(p);
}
```
Re: Setting field of struct object
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 = Person("Tom", "joel...@gmail.com", 44);
writeln(p);
}
```
Re: Setting field of struct object
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(
name: "Tom",
email: "joel...@gmail.com",
age: 44,
);
writeln(p);
}
```
Re: Setting field of struct object
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=email; return
this; }
auto withAge(ulong age) { this.age=age; return this; }
}
void main() {
Person p;
p.withName("Tom").withEmail("joel...@gmail.com").withAge(44);
writeln(p);
}
```
VS:`C++`
```d
struct Person {
string name, email;
ulong age;
}
Person a{"n","email",33};
```
What about in D:
auto a=Person(“n”, “email”, 33);
Re: Setting field of struct object
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) { this.age=age; return this; }
}
void main() {
Person p;
p.withName("Tom").withEmail("joel...@gmail.com").withAge(44);
writeln(p);
}
```
VS:`C++`
```d
struct Person {
string name, email;
ulong age;
}
Person a{"n","email",33};
```
Re: Setting field of struct object
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 withName(string name) { this.name=name; return this; }
auto withEmail(string email) { this.email=email; return this;
}
auto withAge(ulong age) { this.age=age; return this; }
}
void main() {
auto p = (new Person).withName("Tom")
.withEmail("joel...@gmail.com")
.withAge(44);
writeln(p);
}
```
If you convert it to a class, add an `static opCall` for
initialization,
and a toString() method, it's even nicer:
```d
module app;
import std;
class Person {
private string name, email;
private ulong age;
auto withName(string name) { this.name=name; return this; }
auto withEmail(string email) { this.email=email; return this;
}
auto withAge(ulong age) { this.age=age; return this; }
static Person opCall() => new Person();
override string toString() {
return "Person{ name: "~name~", age: "~age.to!string~",
email: "~email~" }";
}
}
void main() {
auto p = Person()
.withName("Tom")
.withEmail("joel...@gmail.com")
.withAge(44);
writeln(p);
}
```
It's common OOP style in some frameworks.
Re: Setting field of struct object
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
subsequent methods.
```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) { this.age=age; return this; }
}
void main() {
Person p;
p.withName("Tom").withEmail("joel...@gmail.com").withAge(44);
writeln(p);
}
```
I've lost interest in the video, looks like horrible syntax (F#).
Setting field of struct object
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 {
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) { this.age=age; return this; }
}
void main() {
Person p;
p.withName("Tom").withEmail("joel...@gmail.com").withAge(44);
writeln(p);
}
```
