September 14

On Tuesday, 14 September 2021 at 09:04:02 UTC, Mike Parker wrote:

>

Today, we have more D libraries, but we still frequently make use of C libraries. The rule still makes sense, IMO.

That it's you who says it makes sense speaks strongly for it. You have so often warned about programming in D as if it was some other language, so if you say it still makes sense to be C-like despite the pitfalls, that speaks a lot.

September 14
On Tue, Sep 14, 2021 at 07:01:02AM +0000, Alexey via Digitalmars-d wrote: [...]
> The ability of D to parse C code, doesn't mean it necessarily should use same rules in it's own D code.
[...]

You're mistaken, D does not parse C code. D was just designed in such a way that when a piece of C code happens to parse like D code without syntax errors, it behaves exactly like the equivalent C code. A lot of C code, however, does not parse as D code (you will get syntax errors). In that case, D is free to diverge from C semantics.


T

-- 
Let X be the set not defined by this sentence...
September 14
On Tuesday, 14 September 2021 at 16:53:44 UTC, H. S. Teoh wrote:
> On Tue, Sep 14, 2021 at 07:01:02AM +0000, Alexey via Digitalmars-d wrote: [...]
>> The ability of D to parse C code, doesn't mean it necessarily should use same rules in it's own D code.
> [...]
>
> You're mistaken, D does not parse C code.

Technically it does now, with ImportC.
5 days ago
On 9/13/2021 1:35 PM, Steven Schveighoffer wrote:
> To reiterate, intpromote is going to require lots of casts, most of which wouldn't change any behavior that is currently happening.

Intpromote has been there for many years, it hasn't caused a big problem.

> The cases where the behavior is different is going from 8 or 16-bit integers to higher bit numbers. IMO, intpromote should focus on those, and leave the others alone.

The thing is, if b is a ubyte:

    ~b

is supposed to be an int, not a ubyte. It's not just about getting the bits right.


> But fixing this problem doesn't mean we have to break all existing code for the purpose of busywork to insert casts to achieve the current behavior.

It needs to move to C behavior.

> I just realized, the deprecation doesn't even say how to replicate current behavior. It says to cast to int before applying the operator, but that's not what current behavior does, it's what the *new* behavior does. Typically, deprecations identify how to adjust your code so it continues to do the same thing. This does the opposite.

The message is about inuring your code so it will work as intended regardless of the switch setting.

5 days ago

On 9/15/21 11:58 PM, Walter Bright wrote:

>

On 9/13/2021 1:35 PM, Steven Schveighoffer wrote:

>

To reiterate, intpromote is going to require lots of casts, most of which wouldn't change any behavior that is currently happening.

Intpromote has been there for many years, it hasn't caused a big problem.

It's clear that you aren't going to budge at all on this, but just to respond to this -- -preview=intpromote is not required. It's not a default, and it's not used by default in dub. People are complaining about the excessive casting recommended by the compiler, even though their code works as expected now, and would work as expected after intpromote is the default.

>

It needs to move to C behavior.

In C:

unsigned short a2 = ~a1;

is valid. Why are we not continuing to replicate that behavior?

-Steve

Next ›   Last »
1 2 3 4