I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

• Worst features implemented in a non-toy language
• Worst features (in your opinion) in D
• Features you'd like to see in D

Ideas? Examples?

Thanks!

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

Objectively worst feature: mutability/referenceability by default. It takes away so much optimization potential and introduces so many opportunities for state changes. var = value should be opt-in. Just as importantly, &var should be opt-in.

My D hobbyhorse, of course, is __traits(compiles) (see my last DConf talk) and the SFINAE-like mess that it enables but doesn't give us the tools to address. "Why did the template not instantiate?" Who knows~ That syntax error got suppressed five instantiations down.

And there's obvious stuff like the half-baked immutable that works in about half the stdlib and a smaller fraction of libraries. D2 const was a mistake, cmv. (Nonreferenceability allows safe reassignment of immutable struct member fields, btw!)

But I'm actually convinced that the worst thing is the lack of implicit construction for sumtypes. Because when you try to actually use sumtypes, you end up with stuff like Nullable!MySumType(MySumType(MemberType("Hello World"))). All over the place. And it adds no value! The whole point of MySumType is that it's "one of n types, including MemberType". Writing out the full type of a nested container type like that adds nothing of value.

Sumtypes should be built-in, and they should implicitly construct from its member types.

PS: But staring at this post interface, what I want the most right now - a "Discard all drafts" button. :)

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

Two things that immediately come to mind:

• unittest. Clutters code reading, discourages extensive testing (because of said clutter), discourages testing inside a user's module, complicates runtime and compiler, framework cannot be developed separate from language runtime, ...

• Implicit pointer/reference type of classes. While I think the forced reference type of classes is a good idea (when passing as function argument), I think it was a very bad idea to remove the * from notation. It makes code impossible to interpret without looking up a user-defined type.

-Johan

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

Indirect method notation in Perl: https://stackoverflow.com/questions/11695110/why-is-this-program-valid-i-was-trying-to-create-a-syntax-error/11695310#11695310

wantarray in Perl, where e.g. reverse() either reverses its list of arguments (a list of one argument $a in the following program--a noop) or it reverses the joined string of its list of arguments (the single string $a in the following the program) , depending on what the caller wants:

sub foo {
    my ($a) = @_;
    reverse $a;
}

print foo("unchanged"), "\n";  # output: unchanged
my $changed = foo("changed");
print $changed, "\n";          # output: degnahc

Aliasing subroutine parameters in Perl: sub foo { my $arg = shift; } is not the same thing as sub foo { my ($arg) = @_; } and I can no longer remember why it's super critically important that you use the second form by default.

Autovivification in Perl - usually desirable, and D has it to an extent in AAs. But then there's this:

sub add {
    my ($table, $key) = @_;
    $table->{$key} = 1;
}

my $table;           # undef
add($table, "one");  # undef autovivifies into a hashref ... only within add()
die "that silently did nothing" if exists $table{one};
$table = {};         # an empty hashref
add($table, "two");  # empty hashref is mutated by add()
print $table{two};

Overriding 'built in' functions. Does stat() return the list of fields enumerated in 'perldoc -f stat' or does it return an object? Better check and see if the program you're maintaining used File::stat or not.

$_ as the default argument in Perl. Literally once a month I write this code:

open my $f, '<', 'open some file to read'
    or die "Tried to open 'some file to read' and failed : $!";
while (defined(my $line = <$f>)) {
    next unless /oh goddamnit this regex is applying to $_ and not $line/;
    do_stuff;
}

Perl has a lot of "wow, that was a horrible idea! Let's fix it by adding a new syntax, encouraging people to use that instead, and then leaving this horrible idea in the language forever." misfeatures. The separate '<' in the previous example is some new syntax for opening files. The old syntax lets you write tools that will truncate /etc/passwd or spawn arbitrary subprocesses if given a malicious filename. At least those dangerous tools never stopped working due to the language updating and breaking them, right?

Maybe it's not surprising by this point of this post, but I'm pretty happy with D.

I would like some easy way to make sure I haven't accidentally used 80-bit floats in a D program.

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

• Some C standard library functions. gets is the worst one, but atof and atoi are pretty useless too.

• The feature of some early C compilers that only the first 7 characters of an identifier are significant.

• C casting and C++ template syntaxes.

• Disallowed free functions in Java and C#

• More than one feature of C# structs.

• Integer promotion without at least letting to assign the result back to original width without a cast

• Autodecoding. It would not be as bad if string literals were of some sort of wrapper type over the data, but autodecoding a plain array type just sucks.

• The Phobos versioning scheme that is already in the works.

• Some way to enable preview/revert switches per module as opposed to per compilation. And same for autodecoding if possible.

• More compatibility between compiler / standard library versions in general.

• Perhaps we should have a common agreement on what compiler versions should be used when long-term support for code is the goal. For example, we could agree on 2.084, 2.090, 2.096, 2.102 etc.

On Monday, 11 October 2021 at 16:12:59 UTC, FeepingCreature wrote:

• features that require a GC (associative array)

• class (reference type)

I 100% agree with you

Tagged union SHOULD be built in, telling people to import a package and use them like templates is the best way to discourage people from getting interested in the language

When other "modern" languages don't have the problem since it's built in feature

The positive side of std.sumtype is it showcase the capabilities of the language to implement new features on user land, BUT, for sumtype, nobody should have to go that road..

Same for Nullable/Optional in my opinion

On Monday, 11 October 2021 at 17:06:38 UTC, Johan wrote:

Nothing prevents you from pulling out the unittests (except maybe documented ones) and putting them in a separate file or folder structure. In fact, it should probably be more commonly done...

It's been a while i haven't used anything other than D, so i don't have much to say, i'll need to research to remember first

On top of my head, i think the worst feature in any language is C/C++ header system

Sometimes, in rare occasions it can be handy, but most of the time it is a pain in the butt

- class (reference type)
- GC as a feature
- !() for templates (not really a feature, more like a syntax issue, way to similar to functions)
- being abot to use ! with optional parentheses, countless times i got bit by:
    ``Array!int* array;``  but i wanted ``Array!(int)* array;`` instead..

- tagged union (built in, not as std/lib)
- interface / signature for structs (built in, not as std/lib)
    - alternatively, reintroduce the * for classes
- enum literals (being able to omit the enum name)
    ex:
        ```d
        enum MyEnum { A, B, C}
        MyEnum e = :A;
        my_function(:A);
        switch (e)
        {
        case :A: break;
        }
        // could be :, ., $, ! but that is not the point
        '''

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

C's pointer notation is too stupid for words. (I understand how it works. I've been using it for decades. Please no explanations.)

Writing functions like this is horrible:

int timesTwo(int *x) {
	return 2 * *x;
}

When you learn C, you ask what the *x is. It's an int. That makes sense. That's why it's int *x. Okay, let's call that function:

int main() {
	printf("%d\n", timesTwo(4));
	return 0;
}

expected ‘int *’ but argument is of type ‘int’

Okay, let's try this:

int main() {
	int z = 4;
	printf("%d\n", timesTwo(&z));
	return 0;
}

8

So *x is an int, but you have to pass &z, which is not an int, as the argument. The only way this can't be confusing to someone learning it for the first time is if they're memorizing syntax.