www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Language Reference

reply Pete <sdk x.com> writes:
I'm starting to learn the D language and started reading the 
Language Reference.  Trying some examples, I noted that the 
compilers are flagging some things as deprecated while the 
Language Reference has no indication of this. Main example, the 
cent/ucent data types.  The compiler (ldc2 1.39.0) indicated 
cent/ucent as obsolete and to use core.int128.Cent, but I 
couldn't find that in the standard library site (in core)...but 
found std.Int128. Am I missing something? Is the Language 
Reference not being updated or the compilers running way ahead of 
it?

Thanks
Aug 17
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 17 August 2024 at 22:17:59 UTC, Pete wrote:

 I'm starting to learn the D language and started reading the 
 Language Reference


dont; spec is full of lies and slaunder

my thing is over here: https://github.com/crazymonkyyy/dingbats

I think this book over hyped, and if I dont link it 10 poeple 
will yell at me(as opposed to the 3 who will anyway) the book is 
better then the spec https://ddili.org/ders/d.en/index.html
Aug 17
parent reply Nick Treleaven <nick geany.org> writes:
On Sunday, 18 August 2024 at 01:31:37 UTC, monkyyy wrote:

 spec is full of lies and slaunder


If you know of specific inaccuracies or omissions, please file 
bugs.
Aug 19
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 19 August 2024 at 16:03:59 UTC, Nick Treleaven wrote:

 On Sunday, 18 August 2024 at 01:31:37 UTC, monkyyy wrote:

 spec is full of lies and slaunder


 If you know of specific inaccuracies or omissions, please file 
 bugs.


You should only ask for bug reports of people who dont have 
active year old ones; I will cynically pick and choose when I 
bother
Aug 19
parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 19 August 2024 at 19:02:06 UTC, monkyyy wrote:

 You should only ask for bug reports of people who dont have 
 active year old ones;


Spec bugs are usually easy to fix. Even if a bug doesn't get 
fixed, it's still valuable to have bugs filed.
Aug 20
parent monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 20 August 2024 at 16:27:35 UTC, Nick Treleaven wrote:

 On Monday, 19 August 2024 at 19:02:06 UTC, monkyyy wrote:

 You should only ask for bug reports of people who dont have 
 active year old ones;


 Spec bugs are usually easy to fix. Even if a bug doesn't get 
 fixed, it's still valuable to have bugs filed.


https://issues.dlang.org/show_bug.cgi?id=24205

my spec bugs dont get fixed either
Aug 20
prev sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 19 August 2024 at 16:03:59 UTC, Nick Treleaven wrote:

 On Sunday, 18 August 2024 at 01:31:37 UTC, monkyyy wrote:

 spec is full of lies and slaunder


 If you know of specific inaccuracies or omissions, please file 
 bugs.


Honestly, all examples should be runnable, except for good 
reasons when they can’t.
Aug 20
parent Nick Treleaven <nick geany.org> writes:
On Tuesday, 20 August 2024 at 13:04:08 UTC, Quirin Schroll wrote:

 Honestly, all examples should be runnable, except for good 
 reasons when they can’t.


Just to note: aside from incomplete snippets, they can't be 
runnable at the moment if:
* They need `-preview` switches
* If they depend on a higher compiler version than run.dlang.org 
has (which should only be unreleased versions).
* If they need multiple modules

There are still some which could be made runnable, although I 
think we've been making quite a lot of progress in recent years.
Aug 20
prev sibling next sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Saturday, 17 August 2024 at 22:17:59 UTC, Pete wrote:

 Trying some examples, I noted that the compilers are flagging 
 some things as deprecated while the Language Reference has no 
 indication of this.


Could you send a link to those examples?


 Main example, the cent/ucent data types.  The compiler 
 (ldc2 1.39.0) indicated cent/ucent as obsolete


Yes, the keywords are deprecated: 
https://dlang.org/spec/lex.html#keywords
`cent`/`ucent` as built-in types were never implemented.


 and to use core.int128.Cent, but I couldn't find that in the 
 standard library site (in core)...but found std.Int128.


You probably didn’t find it because you were looking under the 
`std` package, not the `core` package.
However, 
[`core.int128`](https://dlang.org/phobos/core_int128.html) is 
just a plain data type & a bunch of maths functions like 
`add`/`div`/`mul`/etc. that operate on it—it’s a set of building 
blocks. 
[`std.int128.Int128`](https://dlang.org/phobos/std_int128.html#.Int128) turns
those functions into appropriate operator overloads. However, I would actually
recommend [this library](https://codemirror.dlang.org/packages/speedy-int128)
because it’s exactly the same except that when using LDC2 it produces
significantly faster code.


 Am I missing something?
 Is the Language Reference not being updated or the compilers 
 running way ahead of it?


Sometimes the spec misses some information, it’s just human 
error. In general dmd’s implementation is a higher authority, but 
sometimes it has bugs too. If you notice something missing from 
the spec, then please file an issue or submit a PR.
Aug 18
parent Pete <x x.com> writes:
On Sunday, 18 August 2024 at 08:28:48 UTC, IchorDev wrote:

 On Saturday, 17 August 2024 at 22:17:59 UTC, Pete wrote:

 [...]


 Could you send a link to those examples?


 [...]


 Yes, the keywords are deprecated: 
 https://dlang.org/spec/lex.html#keywords
 `cent`/`ucent` as built-in types were never implemented.

 [...]


Calling them examples was not quite correct - I just did simple 
programs. Appreciate the link to speedy-int128. Thank you.
PS. will submit an issue.
Aug 18
prev sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Saturday, 17 August 2024 at 22:17:59 UTC, Pete wrote:

 I'm starting to learn the D language and started reading the 
 Language Reference.


I've never read the reference, but I can tell you that [**The 
Book**](https://ddili.org/ders/d.en/index.html) (over-hyped or 
not) gives you a solid grounding. It's the only D 
reference/tutorial that's kept more-or-less up-to-date (I say at 
the risk of excessive hyphenation). You may or may not find it 
slow going, depending on your taste, but at this point, it's the 
best we have for getting in there are getting your feet wet.

If you're new to computer science, it covers basics I first 
learned back in the mid-1980's, the kind of stuff rarely 
mentioned these days that lends one a solid understanding of 
these machines we all love to tinker with.
Aug 18
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 19 August 2024 at 06:47:10 UTC, Ron Tarrant wrote:

 The Book
 If you're new to computer science, it covers basics I first 
 learned back in the mid-1980's,


Which is terrible

No one needs yet another explanation on what floats are

The core d languge should be a light 50 pages; templates can then 
be dense 500 pages
Aug 19
parent reply user1234 <user1234 12.de> writes:
On Monday, 19 August 2024 at 19:14:19 UTC, monkyyy wrote:

 On Monday, 19 August 2024 at 06:47:10 UTC, Ron Tarrant wrote:

 The Book
 If you're new to computer science, it covers basics I first 
 learned back in the mid-1980's,


 Which is terrible

 No one needs yet another explanation on what floats are

 The core d languge should be a light 50 pages; templates can 
 then be dense 500 pages


So much less is required. Templates are much more easy to get 
that you think. A single page is enough. To be a bit provocative 
it's jut about filling the holes.
Then it becomes a bit more complex when it's about overloading... 
but essentially templates are incomplete syntax trees that you 
complete with arguments. Dead stupid.

Now sure D adds a bit of complexity over that simple concept. How 
?
1. constraints. Well well well, isn't that thing just made to 
deal with overloading ;)
2. eponymous declarations

Otherwise, the other big thing to get is that template instances 
can insert new things in the AST. The compiler deals with that 
quite nicely because it's "multi-pass".
Aug 19
parent monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 19 August 2024 at 20:17:58 UTC, user1234 wrote:

 On Monday, 19 August 2024 at 19:14:19 UTC, monkyyy wrote:

 The core d languge should be a light 50 pages; templates can 
 then be dense 500 pages


 So much less is required. Templates are much more easy to get 
 that you think. A single page is enough. To be a bit 
 provocative it's jut about filling the holes.
 Then it becomes a bit more complex when it's about 
 overloading... but essentially templates are incomplete syntax 
 trees that you complete with arguments. Dead stupid.

 Now sure D adds a bit of complexity over that simple concept. 
 How ?
 1. constraints. Well well well, isn't that thing just made to 
 deal with overloading ;)
 2. eponymous declarations

 Otherwise, the other big thing to get is that template 
 instances can insert new things in the AST. The compiler deals 
 with that quite nicely because it's "multi-pass".


I havnt yet seen coherent explanations for the ~~bugs~~ features 
I know, much less concise ones. Spooky quantum effects, the order 
of compilation, the syntax of sequences, the mix file having 
effects, breaking down overload sets, traits and honestly their 
bad api, is statements, etc.

Im quite sure it isnt only a page
Aug 19
prev sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Monday, 19 August 2024 at 06:47:10 UTC, Ron Tarrant wrote:

 On Saturday, 17 August 2024 at 22:17:59 UTC, Pete wrote:

 I'm starting to learn the D language and started reading the 
 Language Reference.


 I've never read the reference, but I can tell you that [**The 
 Book**](https://ddili.org/ders/d.en/index.html) (over-hyped or 
 not) gives you a solid grounding. It's the only D 
 reference/tutorial that's kept more-or-less up-to-date (I say 
 at the risk of excessive hyphenation). You may or may not find 
 it slow going, depending on your taste, but at this point, it's 
 the best we have for getting in there are getting your feet wet.

 If you're new to computer science, it covers basics I first 
 learned back in the mid-1980's, the kind of stuff rarely 
 mentioned these days that lends one a solid understanding of 
 these machines we all love to tinker with.


If you like to stay on the bleeding edge then it’s… certainly out 
of date.

The book also says slices are reference types, which is 
completely erroneous. Where associative array or class variables 
are simply a pointer that is not semantically treated as one 
(i.e. no dereferencing is required), slices are more complicated.
Here’s the book’s example of a value type:
```d
void reduceEnergy(double energy) {
     energy /= 4;
}
```
As you can see, since we only modified a value type—even though 
its new value was derived from the old one—nothing happens and 
this function is actually useless. Now, let’s see their deceptive 
presentation of slices as reference types:
```d
void makeFirstLetterDot(dchar[] str) {
     str[0] = '.';
}
```
Oh, see? It’s totally a reference type, because this modifies the 
same data as at the caller site. But hang on, by that logic 
*this* is also a ‘reference type’:
```d
struct DCharArray{
   dchar* ptr;
   size_t length;
}
void makeFirstLetterDot(DCharArray str){
     str[0] = '.';
}
```
What the book misses is the proper explanation that despite 
*containing* a pointer—which is a reference by its very 
nature—slices are still value types because they also incorporate 
a length, which is copied:
```d
void reduceLength(dchar[] str){
     str = str[0..$-1];
}
```
This does nothing, because we modified the slice’s length, and 
the slice’s length is copied rather than referenced. Notice that 
the pointer remains the same, which distinguishes this from the 
behaviour of reassigning to an associative array or class 
variable; wherein a new instance will be distinct from the old 
one, and writing to its value fields will not directly affect the 
old instance.
Aug 19
next sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Tuesday, 20 August 2024 at 04:53:16 UTC, IchorDev wrote:

 If you like to stay on the bleeding edge then it’s… certainly 
 out of date.


Yeah, yeah...
I didn't say it was perfect. Read this carefully (I'll repeat 
myself):

It's the only D reference/tutorial that's kept more-or-less 
up-to-date.

Prove me wrong by citing something more up-to-date and I'll 
gladly retract. Otherwise, go find someone else to troll.
Aug 20
next sibling parent reply Renato Athaydes <renato athaydes.com> writes:
On Wednesday, 21 August 2024 at 06:45:38 UTC, Ron Tarrant wrote:

 On Tuesday, 20 August 2024 at 04:53:16 UTC, IchorDev wrote:

 If you like to stay on the bleeding edge then it’s… certainly 
 out of date.


 Yeah, yeah...
 I didn't say it was perfect. Read this carefully (I'll repeat 
 myself):

 It's the only D reference/tutorial that's kept more-or-less 
 up-to-date.

 Prove me wrong by citing something more up-to-date and I'll 
 gladly retract. Otherwise, go find someone else to troll.


I agree that the D Book is great. I don't understand why 
criticize it for tiny inaccuracies among a sea of great content, 
no book is perfect. Why not contribute to the book instead of 
rant about it here. Such negativity seems to come from a place of 
anger, not genuinely from trying to help the discussion and the 
correctness of general content about D.
Aug 20
parent reply IchorDev <zxinsworld gmail.com> writes:
On Wednesday, 21 August 2024 at 06:53:24 UTC, Renato Athaydes 
wrote:

 I agree that the D Book is great. I don't understand why 
 criticize it for tiny inaccuracies among a sea of great 
 content, no book is perfect.


So, your logic is that criticism of something that is mostly 
great does not make sense? Now, apply this logic to another 
situation and perhaps you’ll see how it’s this logic that does 
not make sense. You can’t tell me you’ve never seen a great TV 
show that had a couple of bad episodes, eaten something delicious 
that left behind a much less pleasant aftertaste, or had a friend 
who was mostly very kind except for occasionally being racist. 
Overlooking flaws simply because they do not represent a 
sufficient percentage of a whole is foolish if not dangerous.


 Why not contribute to the book instead of rant about it here.


It’s not a public git repository with issues & PRs open, it’s a 
book with a single author. I’m not responsible for the 
publication of some random person and they’re not exactly asking 
for help on their website. If anything, I think it would be quite 
rude to contact them unsolicited to request that they change 
their book based on what I think. The book is allowed to be 
wrong, and I’m allowed to say that it’s wrong so that people know.


 Such negativity seems to come from a place of anger, not 
 genuinely from trying to help the discussion and the 
 correctness of general content about D.


You think that disagreeing with the book for explaining slices in 
a way that’s bound to cause confusion and frustration for 
learners is ‘not […] trying to help the discussion’? So you are 
criticising me for criticising something because you think 
criticism is unproductive? What a self-defeating argument. If you 
think criticism is ‘negativity’ and ‘angry’, then you must say 
nothing unfavourable of such criticism; lest you participate in 
the very same activity. Yet the true struggle is for the 
superiority of ideas, and you have added nothing to this 
conversation of any value.
Aug 21
parent reply Renato <renato athaydes.com> writes:
On Wednesday, 21 August 2024 at 23:05:34 UTC, IchorDev wrote:

 On Wednesday, 21 August 2024 at 06:53:24 UTC, Renato Athaydes 
 wrote:

 I agree that the D Book is great. I don't understand why 
 criticize it for tiny inaccuracies among a sea of great 
 content, no book is perfect.


 So, your logic is that criticism of something that is mostly 
 great does not make sense? Now, apply this logic to another 
 situation and perhaps you’ll see how it’s this logic that does 
 not make sense.


I've come to realize from other threads that you tend to 
misrepresent, or simply misunderstand, what people say quite 
often. I would ask you this: please stop considering us your 
enemy to be beaten in these threads... this is not a competition. 
Noone here is or should be hostile to others.

You've basically misinterpreted "this is not the place to 
criticize the book" as "yo must not criticize anything". I hope 
it's clear to anyone that this is not a charitable interpretation.



 It’s not a public git repository with issues & PRs open, it’s a 
 book with a single author. I’m not responsible for the 
 publication of some random person and they’re not exactly 
 asking for help on their website. If anything, I think it would 
 be quite rude to contact them unsolicited to request that they 
 change their book based on what I think. The book is allowed to 
 be wrong, and I’m allowed to say that it’s wrong so that people 
 know.


I was hoping that you would prefer to write a polite email to the 
author explaining what you see as problematic content on the 
book, and perhaps they would consider improving it. Github is not 
the only way you can contribute to things.


 Such negativity seems to come from a place of anger, not 
 genuinely from trying to help the discussion and the 
 correctness of general content about D.


 You think that disagreeing with the book for explaining slices 
 in a way that’s bound to cause confusion and frustration for 
 learners is ‘not […] trying to help the discussion’?


Yes. Because the question has nothing to do with that. The book 
is more than appropriate according to most people in this Forum 
from what I've seen, and is endorsed by Andrei Alexandrescu in 
the Foreword. Also, I just think you're again twisting a bit what 
the book says to make it sound wrong when it can be reasonably 
interpreted as correct.


 So you are criticising me for criticising something because you 
 think criticism is unproductive? What a self-defeating 
 argument. If you think criticism is ‘negativity’ and ‘angry’, 
 then you must say nothing unfavourable of such criticism; lest 
 you participate in the very same activity. Yet the true 
 struggle is for the superiority of ideas, and you have added 
 nothing to this conversation of any value.


No, again, please stop misrepresenting things. All I am asking 
you is to look in the mirror and think a little bit about why 
nearly all your comments on this Forum sound angry and ranting, 
instead of helpful and to the point. I am trying to find positive 
interactions here, like I hope most of the others. I feel like 
you're preventing that quite a bit with comments like this and 
the one I was criticizing.

I appologize for everyone else for indulging in completely 
unrelated drama, I promise I will avoid doing that from now on.
Aug 25
parent monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 25 August 2024 at 18:52:26 UTC, Renato wrote:

 
 I was hoping that you would prefer to write a polite email to 
 the author explaining what you see as problematic content on 
 the book,


What odds of success do you expect?
Aug 25
prev sibling parent IchorDev <zxinsworld gmail.com> writes:
On Wednesday, 21 August 2024 at 06:45:38 UTC, Ron Tarrant wrote:

 On Tuesday, 20 August 2024 at 04:53:16 UTC, IchorDev wrote:

 If you like to stay on the bleeding edge then it’s… certainly 
 out of date.


 It's the only D reference/tutorial that's kept more-or-less 
 up-to-date.

 Prove me wrong by citing something more up-to-date and I'll 
 gladly retract.


A much more up-to-date reference would be… well, the language 
reference??
After skimming a few relevant chapters, it seems that the book 
doesn’t mention [IES](https://dlang.org/spec/istring.html), 
doesn’t mention [named function 
arguments](https://dlang.org/spec/expression.html#argument-list), 
doesn’t mention [shortened function 
declaration](https://dlang.org/spec/function.html#function-bodies), doesn’t
mention the more sensible new [`alias this`
syntax](https://dlang.org/spec/struct.html#alias-this), and refers to
`cent`/`ucent` as ‘reserved for future use’ rather than ‘[deprecated
keywords](https://dlang.org/spec/lex.html#keywords)’. And don’t try to
weasel out of this by saying that the official D language reference—the only
D reference I use on a regular basis—isn’t what you meant by a
‘reference’ after telling me to ‘read carefully’. The word read
carefully is presumed written carefully.
Aug 21
prev sibling parent reply Lance Bachmeier <no spam.net> writes:
On Tuesday, 20 August 2024 at 04:53:16 UTC, IchorDev wrote:

 On Monday, 19 August 2024 at 06:47:10 UTC, Ron Tarrant wrote:

 On Saturday, 17 August 2024 at 22:17:59 UTC, Pete wrote:

 I'm starting to learn the D language and started reading the 
 Language Reference.


 I've never read the reference, but I can tell you that [**The 
 Book**](https://ddili.org/ders/d.en/index.html) (over-hyped or 
 not) gives you a solid grounding. It's the only D 
 reference/tutorial that's kept more-or-less up-to-date (I say 
 at the risk of excessive hyphenation). You may or may not find 
 it slow going, depending on your taste, but at this point, 
 it's the best we have for getting in there are getting your 
 feet wet.

 If you're new to computer science, it covers basics I first 
 learned back in the mid-1980's, the kind of stuff rarely 
 mentioned these days that lends one a solid understanding of 
 these machines we all love to tinker with.


 If you like to stay on the bleeding edge then it’s… certainly 
 out of date.

 The book also says slices are reference types, which is 
 completely erroneous.


That terminology didn't originate with Ali. You don't like it, 
fine, but he's not wrong based on the usage I've seen here in the 
last decade.
Aug 21
parent IchorDev <zxinsworld gmail.com> writes:
On Wednesday, 21 August 2024 at 15:50:25 UTC, Lance Bachmeier 
wrote:

 That terminology didn't originate with Ali. You don't like it, 
 fine, but he's not wrong based on the usage I've seen here in 
 the last decade.


It’s not as simple as just the terminology. The way they explain 
it, slices are no different to reference types like classes and 
AAs. The issue being that slices are a black sheep among that 
flock because they are more than just a pointer.
Irritatingly, the spec really leans towards this conflation, but 
at least never really says it outright.
Aug 21