August 14, 2020
On 8/14/2020 6:32 AM, Adam D. Ruppe wrote:
> just I don't care, I want 16 bit operations here.

The design considerations are mutually incompatible:

1. performance
2. aesthetics
3. requiring casts breaks generic code
4. should be able to index the entire address space
5. I need wraparound arithmetic
6. I need saturation arithmetic
7. must throw exception on overflow/underflow
8. must not throw exception on overflow/underflow
9. should work like 3rd grade arithmetic
10. type inference
11. should work like C
12. should work like C#
13. should work like Java
14. should work like Python

Language design is an art where we do the best we can given what the language use is targeted at.

D is meant for high performance, systems programming, memory safety, and C compatibility. The compromises go in that direction.
August 14, 2020
On Friday, 14 August 2020 at 21:29:42 UTC, Walter Bright wrote:
> On 8/14/2020 6:32 AM, Adam D. Ruppe wrote:
>> just I don't care, I want 16 bit operations here.
>
> The design considerations are mutually incompatible:
>
> 1. performance
> 2. aesthetics
> 3. requiring casts breaks generic code
> 4. should be able to index the entire address space
> 5. I need wraparound arithmetic
> 6. I need saturation arithmetic
> 7. must throw exception on overflow/underflow
> 8. must not throw exception on overflow/underflow
> 9. should work like 3rd grade arithmetic
> 10. type inference
> 11. should work like C
> 12. should work like C#
> 13. should work like Java
> 14. should work like Python

I think most people would rather not have it work like C, or as a compromise work like C and have warnings like C as it is bug prone. Both those are better than what D is doing now. Trying to make it look like a strawmans, it seems there's a disconnect between designers and users that write actual code.


> Language design is an art where we do the best we can given what the language use is targeted at.
>
> D is meant for high performance, systems programming, memory safety, and C compatibility. The compromises go in that direction.

Most people looking for language that is for high performance and systems programming would probably not want a GC. They can not use the GC but a lot of features are lost because they specifically cator to the GC.

August 17, 2020
On 8/13/20 6:13 AM, FeepingCreature wrote:
> On Thursday, 13 August 2020 at 10:10:34 UTC, H. S. Teoh wrote:
>> On Thu, Aug 13, 2020 at 07:22:18AM +0000, mw via Digitalmars-d wrote: [...]
>>> void main() {
>>>   long   a = -5000;
>>>   size_t b = 2;
>>>   long   c = a / b;
>>>   writeln(c);
>>> }
>>
>> You're mixing signed and unsigned values. That's generally dangerous territory where integer promotion rules inherited from C/C++ take over and cause sometimes weird effects, like here. Changing integer promotion rules will probably never happen now, because it will cause massive *silent* breakage of existing code. So, in the spirit of defensive programming, I recommend avoiding mixing signed/unsigned values in this way.
>>
>>
>> T
> 
> Changing integer promotion rules to disallow promotion of signed to unsigned for division will not cause massive silent breakage. - But it will cause massive visible breakage; Phobos uses this all over.

I wonder if such a change would uncover any bugs in phobos.
August 17, 2020
On 8/13/20 9:40 AM, FeepingCreature wrote:
> On Thursday, 13 August 2020 at 13:33:19 UTC, bachmeier wrote:
>> That's why that behavior needs to be changed as well. It's horrible to implicitly cast from int to double when doing so results in obviously wrong behavior. Hopefully there won't be any more talk about safe by default as long as the language has features like this that are obviously broken and trivially fixed.
> 
> It's not trivially fixed. :-(
> 
> I added a check for this case in DMD, just to see, and it breaks Phobos all over. Anything that interfaces to C with more complicated struct types does division with mixed signs. There'd need to be a lot of casts added as a result of changing this.

Maybe a solution would be to only reject code with integrals statically knoen to be negative that are converted to unsigned integrals. Most of those are arguably bugs.
August 17, 2020
On 8/14/20 5:29 PM, Walter Bright wrote:
> On 8/14/2020 6:32 AM, Adam D. Ruppe wrote:
>> just I don't care, I want 16 bit operations here.
> 
> The design considerations are mutually incompatible:
> 
> 1. performance
> 2. aesthetics
> 3. requiring casts breaks generic code
> 4. should be able to index the entire address space
> 5. I need wraparound arithmetic
> 6. I need saturation arithmetic
> 7. must throw exception on overflow/underflow
> 8. must not throw exception on overflow/underflow
> 9. should work like 3rd grade arithmetic
> 10. type inference
> 11. should work like C
> 12. should work like C#
> 13. should work like Java
> 14. should work like Python

Heh, this looks like a list of things CheckedInt is supposed to help with.

August 17, 2020
On Monday, 17 August 2020 at 11:11:22 UTC, Andrei Alexandrescu wrote:
> On 8/13/20 6:13 AM, FeepingCreature wrote:
>> Changing integer promotion rules to disallow promotion of signed to unsigned for division will not cause massive silent breakage. - But it will cause massive visible breakage; Phobos uses this all over.
>
> I wonder if such a change would uncover any bugs in phobos.

...

On Monday, 17 August 2020 at 11:24:08 UTC, Andrei Alexandrescu wrote:
> On 8/14/20 5:29 PM, Walter Bright wrote:
>> On 8/14/2020 6:32 AM, Adam D. Ruppe wrote:
>>> just I don't care, I want 16 bit operations here.
>> 
>> The design considerations are mutually incompatible:
>> 
>> 1. performance
...
>> 14. should work like Python
>
> Heh, this looks like a list of things CheckedInt is supposed to help with.

That's why I did this study: use checkedint as a drop-in replacement of native long

https://forum.dlang.org/thread/omskttpjhwmmhifymiha@forum.dlang.org

and logged this bug:

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

If we can have these enhancements fixed faster, we will be able to quickly test the replacement in any library (even better with a compiler command line option to activate the switch).

August 19, 2020
On 8/17/2020 4:24 AM, Andrei Alexandrescu wrote:
> Heh, this looks like a list of things CheckedInt is supposed to help with.


Exactly :-)
August 20, 2020
On Friday, 14 August 2020 at 09:12:50 UTC, Walter Bright wrote:
> On 8/13/2020 10:47 PM, Simen Kjærås wrote:
>> This does not in any way address the problem here, namely that the intuitive way to do things causes issues in possibly-very-rare situations.
>
> On a more personal note, I came to C from Pascal. Pascal required explicit casts everywhere one did mixed integer arithmetic. I grew to dislike it, it was ugly and just plain annoying.

IMO that's the most important point. If we were to make it a warning, it would trigger *everywhere* and very often on valid code. The signal to noise ratio would be terrible, as it currently is for C++ code.

I really think there is room for improvement, but anything that would trigger false positive I would strongly oppose. In D I never feels like I have to please the compiler, because errors are almost always sane. In C++, you always have to throw a few compiler switches (`-Wall -Wextra`) and then write your code so that the compiler is happy. No thanks.

If anyone want an example of bad warnings in D: https://issues.dlang.org/show_bug.cgi?id=14835
August 20, 2020
On Thursday, 20 August 2020 at 01:25:17 UTC, Walter Bright wrote:
> On 8/17/2020 4:24 AM, Andrei Alexandrescu wrote:
>> Heh, this looks like a list of things CheckedInt is supposed to help with.
>
>
> Exactly :-)

@Walter,

We also found issues that better to be fixed by the compiler:

https://forum.dlang.org/thread/omskttpjhwmmhifymiha@forum.dlang.org?page=2

on the 2 page of the thread.

In particular:

https://issues.dlang.org/show_bug.cgi?id=21175
1 2 3 4 5 6 7
Next ›   Last »