Regarding the proposed Binray Literals Deprecation (page 14)

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote: > On 9/13/2022 7:56 PM, Steven Schveighoffer wrote: >> But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear. > > Does sometimes justify a language feature, when there are other ways? > > People often complain that D has too many features. What features would you say are not worth it? Classes, private, immutable, udas, attributes, contracts, dmd having optimizations(everyone who needs them will use ldc), expectations, betterc, playing with c++ and objective c

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

People often complain that D has too many features. What features would you say are not worth it?

Hex/binary/octal literals are perceived as a single feature. Removing some of them would actually complicate the language by introducing an inconsistency into that feature (see Timon's post).

What really simplifies a language is removal of inconsistencies and special cases, and also improvement of interactions between features. For example, we are now struggling with the impossibility to perfectly forward a variadic function call:

void bar(short a)
{
}

void foo(alias target, A...)(auto ref A args)
{
    target(forward!args);
}

void main()
{
    bar(1); // ok
    foo!bar(1); // error because args[0] is inferred as int
}

We now have to force superfluous casts on the API user, or resort to all kinds of metaprogramming hackery, or go back to Java-style monkey-coding.

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote: > On 9/13/2022 7:56 PM, Steven Schveighoffer wrote: >> But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear. > > Does sometimes justify a language feature, when there are other ways? Yes, definitely. Why use `foreach` sometimes when you have `for`, `while` and even `goto` to do it in another way? > > People often complain that D has too many features. What features would you say are not worth it? Clumsy Phobos solutions to replace simple elegant consistent language syntax. For complex numbers, the language complexity it involves compared to a library solution is probably justified. For the `0b` literals definitively not.

September 14, 2022

Re: Regarding the proposed Binray Literals Deprecation

Posted by Quirin Schroll
in reply to Walter Bright

Permalink

Quirin Schroll

Posted in reply to Walter Bright

Permalink

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:

But it doesn't disprove the fact that sometimes, hex digits aren't as clear.

Does sometimes justify a language feature, when there are other ways?

It’s change not features that must be justified. If a feature is already properly implemented and available for years, removing it must be justified.

It is trivial to justify removal of a feature that was promised by the spec, but never implemented (e.g. cent). It is easy to justify changes on a feature (including removal) that was inconsistent or never worked correctly (I’m no expert, but I remember shared being named in this context).

People often complain that D has too many features. What features would you say are not worth it?

Any feature that works as intended is probably used or even relied upon by someone.

I cannot give you a list, but a criterion. The ones that are worth removing are those that have not worked correctly for years. Apparently, no fix is being found and/or nobody cares enough. It makes sense removing those.

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote: > On 9/13/2022 7:56 PM, Steven Schveighoffer wrote: >> But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear. > > Does sometimes justify a language feature, when there are other ways? > > People often complain that D has too many features. What features would you say are not worth it? This is an example of what I mention at this link below (and in the thread that led to that post). https://forum.dlang.org/post/jslyncewynqaefohloog@forum.dlang.org You argue about compiler-complexity AND user-complexity on this topic. Sometimes one, sometimes the other. It's not always consistent and some can find it confusing.

On 9/14/22 01:43, Patrick Schluter wrote: > `core.bitop.popcnt(check) == 4` would be simpler and most modern CPU's > have an instruction for that. That will give total number of bits set. Steve's function determines whether 5 neighboring bits are set consecutively, anywhere in the "register". And that 4 is a red herring that made me think I found a bug. No, the function finds 5 consecutive bits set by 4 shifts. :) Ali

On Tuesday, 13 September 2022 at 18:50:01 UTC, Walter Bright wrote: > On 9/13/2022 11:07 AM, wjoe wrote: >> Besides, I've had to use the tip of a pencil to count Fs in hex values. > > So have I. But I have only 1/4 as many digits to count, and don't need to if there are 6 or fewer digits. Neither do you if you have only 8 bit especially if you group them with underscores. Even 16 bit would be easy to read like that. ubyte foo = 0b0010_1011; ubyte bar = 0x2b; Task: flip bit 3. foo: 1. overwrite bit 3 with a 0. bar: 1. convert 2b to binary 2. flip the bit 3. convert that back to hex. foo 1 step bar 3 steps Checking which bits are set ? foo - it's obvious at a glance. bar - 2 steps: convert to binary -> read the bit which is user friendlier ?

Forums