On Wednesday, 14 February 2024 at 00:56:21 UTC, Kevin Bailey
wrote:
Personally, I don't have a problem with .length being unsigned.
How do you have a negative length? My problem is that the
language doesn't correctly compare signed and unsigned.
The length itself is technically the index of a
On Tuesday, 13 February 2024 at 23:57:12 UTC, Ivan Kazmenko wrote:
I do use lengths in arithmetic sometimes, and that leads to
silent bugs currently. On the other hand, since going from 16
bits to 32 and then 64, in my user-side programs, I had a flat
zero bugs because some length was 2^{31}
On Thursday, 8 February 2024 at 05:56:57 UTC, Kevin Bailey wrote:
How many times does the following loop print? I ran into this
twice doing the AoC exercises. It would be nice if it Just
Worked.
```
import std.stdio;
int main()
{
char[] something = ['a', 'b', 'c'];
for (auto i = -1; i <
On Tuesday, 13 February 2024 at 23:57:12 UTC, Ivan Kazmenko wrote:
I'd like to note that even C++20 onwards has `.ssize`, which is
signed size.
I do use lengths in arithmetic sometimes, and that leads to
silent bugs currently. On the other hand, since going from 16
bits to 32 and then 64,
On Monday, 12 February 2024 at 19:56:09 UTC, H. S. Teoh wrote:
But regardless, IMNSHO any programmer worth his wages ought to
learn what an unsigned type is and how it works. A person
should not be writing code if he can't even be bothered to
learn how the machine that's he's programming
On Tue, Feb 13, 2024 at 06:36:22PM +, Nick Treleaven via
Digitalmars-d-learn wrote:
> On Monday, 12 February 2024 at 18:22:46 UTC, H. S. Teoh wrote:
[...]
> > Honestly, I think this issue is blown completely out of proportion.
> > The length of stuff in any language needs to be some type. D
On Mon, Feb 12, 2024 at 07:34:36PM +, bachmeier via Digitalmars-d-learn
wrote:
> On Monday, 12 February 2024 at 18:22:46 UTC, H. S. Teoh wrote:
>
> > Honestly, I think this issue is blown completely out of proportion.
>
> Only for people that don't have to deal with the problems it causes.
On Monday, 12 February 2024 at 18:22:46 UTC, H. S. Teoh wrote:
Honestly, I think this issue is blown completely out of
proportion.
Only for people that don't have to deal with the problems it
causes.
D decided on an unsigned type. You just learn that and adapt
your code accordingly, end
On Monday, 12 February 2024 at 17:26:25 UTC, Nick Treleaven wrote:
On Friday, 9 February 2024 at 15:19:32 UTC, bachmeier wrote:
It's been discussed many, many times. The behavior is not
going to change - there won't even be a compiler warning.
(You'll have to check with the leadership for
On Mon, Feb 12, 2024 at 05:26:25PM +, Nick Treleaven via
Digitalmars-d-learn wrote:
> On Friday, 9 February 2024 at 15:19:32 UTC, bachmeier wrote:
> > It's been discussed many, many times. The behavior is not going to
> > change - there won't even be a compiler warning. (You'll have to
> >
On Friday, 9 February 2024 at 15:19:32 UTC, bachmeier wrote:
It's been discussed many, many times. The behavior is not going
to change - there won't even be a compiler warning. (You'll
have to check with the leadership for their reasons.)
Was (part of) the reason because it would disrupt
On Friday, 9 February 2024 at 16:49:37 UTC, Gary Chike wrote:
The underlying architecture of the language will often times
dictate how certain constructs or design decisions are made. For
example in Ada, every array has a `Length` attribute and it
returns an `integer` type.
And since Ada is
On Friday, 9 February 2024 at 12:15:29 UTC, Sergey wrote:
Rust, Nim, Zig, Odin…?
Here is the Forum for D(lang). ;)
But it is fine to see what others have..
Teach on their experience is useful
This is how research is going
Sorry, I probably got confused by the use of different languages
in
On Friday, 9 February 2024 at 12:15:29 UTC, Sergey wrote:
On Friday, 9 February 2024 at 08:04:56 UTC, Danilo wrote:
Rust, Nim, Zig, Odin…?
Here is the Forum for D(lang). ;)
But it is fine to see what others have..
Teach on their experience is useful
This is how research is going
Thank you
On Friday, 9 February 2024 at 11:00:09 UTC, thinkunix wrote:
First off I, I am just a beginner with D. I joined this list
to try to
learn more about the language not to but heads with experts.
I'm sorry
if you took my response that way.
Hi thinkunix,
I did interpret your post as
On Friday, 9 February 2024 at 11:00:09 UTC, thinkunix wrote:
If your issue is that the compiler didn't catch this, shouldn't
you
raise the issue on a compiler internals list? Maybe I've
misunderstood
the purpose of d-learn "Questions about learning and using D".
It's been discussed many,
On Friday, 9 February 2024 at 08:04:56 UTC, Danilo wrote:
Rust, Nim, Zig, Odin…?
Here is the Forum for D(lang). ;)
But it is fine to see what others have..
Teach on their experience is useful
This is how research is going
Kevin Bailey via Digitalmars-d-learn wrote:
On Thursday, 8 February 2024 at 08:23:12 UTC, thinkunix wrote:
I would never write code like this.
By all means, please share with us how you would have written that just
as elegantly but "correct".
First off I, I am just a beginner with D. I
On Friday, 9 February 2024 at 02:55:48 UTC, Gary Chike wrote:
On Friday, 9 February 2024 at 02:13:04 UTC, Gary Chike wrote:
I spoke too soon, it appears Zig's default return type for its
`len()` function is: `usize' - similar to Rust.
```rust
const std = @import("std");
pub fn main() !void
On Friday, 9 February 2024 at 02:13:04 UTC, Gary Chike wrote:
Reviewing the default return type in a couple more newer
languages for the length function or equivalent. (`len()`,
`length()`, `size()`):
The Nim language appears to return an `int` type:
```python
let something = @['a', 'b',
On Thursday, 8 February 2024 at 16:54:36 UTC, Kevin Bailey wrote:
Additionally, it doesn't address the issue. It still requires
me to both realize the issue with comparing an int to length's
mystery type, as well as to fix it for the compiler.
(And it's beside the fact that the start value
On Thursday, 8 February 2024 at 16:54:36 UTC, Kevin Bailey wrote:
[...]
On Thursday, 8 February 2024 at 15:26:16 UTC, kdevel wrote:
Elegant and correct is this version:
```d
import std.stdio;
int main()
{
char[] something = ['a', 'b', 'c'];
writeln("len: ",
Arafel,
You're certainly correct. Priorities change. It used to be
thought that backwards compatibility was the way to attract
developers. But today the keyword is "safety".
Apparently 2022 was the year of the C++ successor. Some features
of D were mentioned in the discussion but D as a
On Thursday, 8 February 2024 at 15:00:54 UTC, Kevin Bailey wrote:
By all means, please share with us how you would have written
that just as elegantly but "correct".
Elegant and correct is this version:
```d
import std.stdio;
int main()
{
char[] something = ['a', 'b', 'c'];
On 8/2/24 16:00, Kevin Bailey wrote:
I'm asking, why is the default C compatibility (of all things) rather
than "safety that I can override if I need to make it faster" ?
I'm sure there are more experienced people here that will be able to
answer better, but as far as I remember, the policy
On Thursday, 8 February 2024 at 08:23:12 UTC, thinkunix wrote:
I would never write code like this.
By all means, please share with us how you would have written
that just as elegantly but "correct".
It would also break if the array 'something' had more than
int.max elements.
Then don't
Kevin Bailey via Digitalmars-d-learn wrote:
How many times does the following loop print? I ran into this twice
doing the AoC exercises. It would be nice if it Just Worked.
```
import std.stdio;
int main()
{
char[] something = ['a', 'b', 'c'];
for (auto i = -1; i < something.length;
On Thursday, 8 February 2024 at 05:56:57 UTC, Kevin Bailey wrote:
I don't think it's productive to compare the behavior to C. C
is now 50 years old. One would hope that D has learned a few
things in that time.
How many times does the following loop print? I ran into this
twice doing the AoC
On Wednesday, 7 February 2024 at 20:13:40 UTC, Gary Chike wrote:
On Wednesday, 7 February 2024 at 20:08:24 UTC, Gary Chike wrote:
On Wednesday, 7 February 2024 at 19:32:56 UTC, Gary Chike
wrote:
double c = (double)sumArray(a, aLength) / aLength;
If I don't cast explicitly:
`double c =
On Wednesday, 7 February 2024 at 20:08:24 UTC, Gary Chike wrote:
On Wednesday, 7 February 2024 at 19:32:56 UTC, Gary Chike wrote:
double c = (double)sumArray(a, aLength) / aLength;
If I don't cast explicitly:
`double c = sumArray(a, aLength) / aLength;`
then I will get a similar
On Wednesday, 7 February 2024 at 19:32:56 UTC, Gary Chike wrote:
On Wednesday, 7 February 2024 at 19:20:12 UTC, Gary Chike wrote:
The output wasn't quite right. So I tweaked it a bit:
```c
long sumArray(long arr[], size_t size) {
long total = 0;
for (size_t i = 0; i < size; ++i) {
On Wednesday, 7 February 2024 at 19:20:12 UTC, Gary Chike wrote:
I just had to transcribe this to C just for grins :D
```c
#include
int sumArray(int arr[], size_t size) {
int total = 0;
for (size_t i = 0; i < size; ++i) {
total += arr[i];
}
return total;
}
int
On Sunday, 28 January 2024 at 17:25:49 UTC, mw wrote:
See the result here:
https://forum.dlang.org/post/cagloplexjfzubncx...@forum.dlang.org
I knew this outlandish output had to do with mixing of signed and
unsigned types with resulting overflow. But I like the way
Anthropic Claude2
I have an idea to estimate how long strlen takes on an exabyte
string.
On Sunday, 28 January 2024 at 16:16:34 UTC, Olivier Pisano wrote:
If .length were to be an int, D could not handle array of more
than 2G bytes. The whole language would be useless on 64 bit
systems.
The array.length better to be *signed* `long` (signed size_t)
instead of unsigned.
Can
On Thursday, 18 January 2024 at 02:55:37 UTC, zjh wrote:
Can you change the type of 'length' from 'ulong' to 'int', so I
haven't to convert it every time!
The devs are obviously very very wrong here I underflow indexs
all the time
But this is a pretty dead fight, I'd aim for a smart index
On Sunday, 28 January 2024 at 16:16:34 UTC, Olivier Pisano wrote:
On Sunday, 28 January 2024 at 08:55:54 UTC, zjh wrote:
On Sunday, 28 January 2024 at 06:34:13 UTC, Siarhei Siamashka
wrote:
The explicit conversion `.length.to!int` has an extra benefit
I rarely use numbers over one million.
On Sunday, 28 January 2024 at 08:55:54 UTC, zjh wrote:
On Sunday, 28 January 2024 at 06:34:13 UTC, Siarhei Siamashka
wrote:
The explicit conversion `.length.to!int` has an extra benefit
I rarely use numbers over one million.
But do I have to consider numbers over `4 billion` every day?
On Sunday, 28 January 2024 at 06:34:13 UTC, Siarhei Siamashka
wrote:
The explicit conversion `.length.to!int` has an extra benefit
I rarely use numbers over one million.
But do I have to consider numbers over `4 billion` every day?
On Thursday, 18 January 2024 at 02:55:37 UTC, zjh wrote:
Can you change the type of 'length' from 'ulong' to 'int', so I
haven't to convert it every time!
The explicit conversion `.length.to!int` has an extra benefit of
doing a runtime check to ensure that the length value actually
fits in
On Thursday, 18 January 2024 at 07:44:00 UTC, Jonathan M Davis
wrote:
```d
auto a = foo();
or
auto len = arr.length;
Thank you for your reply, just to use `auto`.
On Wednesday, January 17, 2024 11:33:48 PM MST zjh via Digitalmars-d-learn
wrote:
> On Thursday, 18 January 2024 at 04:30:33 UTC, Jonathan M Davis
> wrote:
> but for a lot of code, using auto and size_t makes it
>
> > so that you don't need to use int, and it would be a big
> > problem in general
On Thursday, 18 January 2024 at 04:30:33 UTC, Jonathan M Davis
wrote:
but for a lot of code, using auto and size_t makes it
so that you don't need to use int, and it would be a big
problem in general if the language made length int.
It's hard to imagine that an `'int'` needs to be replaced
On Wednesday, January 17, 2024 7:55:37 PM MST zjh via Digitalmars-d-learn
wrote:
> Can you change the type of 'length' from 'ulong' to 'int', so I
> haven't to convert it every time!
If you mean for arrays, length and array indices are specifically size_t so
that their size will match the
44 matches
Mail list logo
