On Tuesday, 28 November 2017 at 04:24:46 UTC, Adam D. Ruppe wrote:
> immutable(int) errorCount() { return ...; }

I actually did try something like that, because I remembered seeing the parens around the string definition. I think at that point I was just so riddled with errors I just took a step back and went back to something I know. Just to make sure I wasn't going insane.

On Tuesday, 28 November 2017 at 03:01:33 UTC, A Guy With an Opinion wrote:

> + D code so far is pushing me towards more "flat" code (for a lack of a better way to phrase it) and so far that has helped tremendously when it comes to readability. C# kind is the opposite. With it's namespace -> class -> method coupled with lock, using, etc...you tend to do a lot of nesting. You are generally 3 '{' in before any true logic even begins. Then couple that with try/catch, IDisposable/using, locking, and then if/else, it can get quite chaotic very easily. So right away, I saw my C# code actually appear more readable when I translated it and I think it has to do with the flatness. I'm not sure if that opinion will hold when I delve into 'static if' a little more, but so far my uses of it haven't really dampened that opinion.

I come from a heavy C#/C++ background.  I also I *felt* this as well, but never really consciously though about it, until you mentioned it :-)

> - Some of the errors from DMD are a little strange. I don't want to crap on this too much, because for the most part it's fine. However occasionally it throws errors I still can't really work out why THAT is the error it gave me. Some of you may have saw my question in the "Learn" forum about not knowing to use static in an embedded class, but the error was the following:
>
> Error: 'this' is only defined in non-static member functions

Please submit things like this to the issue tracker.  They are very easy to fix, and if I'm aware of them, I'll probably do the work.  But, please provide a code example and offer a suggestion of what you would prefer it to say; it just makes things easier.

> - Modules. I like modules better than #include, but I don't like them better than C#'s namespaces. Specifically I don't like how there is this gravity that kind of pulls me to associate a module with a file. It appears you don't have to, because I can do the package thing, but whenever I try to do things outside that one idiom I end up in a soup of errors. I'm sure I'm just not use to it, but so far it's been a little dissatisfying. Sometimes I want where it is physically on my file system to be different from how I include it in other source files. To me, C#'s namespaces are really the standard to beat or meet.

I feel the same.  I don't like that modules are tied to files; it seems like such an arbitrary limitation.  We're not alone:  https://youtu.be/6_xdfSVRrKo?t=353

> - Attributes. I had another post in the Learn forum about attributes which was unfortunate. At first I was excited because it seems like on the surface it would help me write better code, but it gets a little tedious and tiresome to have to remember to decorate code with them. It seems like most of them should have been the defaults. I would have preferred if the compiler helped me and reminded me. I asked if there was a way to enforce them globally, which I guess there is, but I guess there's also not a way to turn some of them off afterwards. A bit unfortunate. But at least I can see some solutions to this.

Yep.  One of my pet peeves in D.

> - The defaults for primitives seem off. They seem to encourage errors. I don't think that is the best design decision even if it encourages the errors to be caught as quickly as possible. I think the better decision would be to not have the errors occur. When I asked about this, there seemed to be a disassociation between the spec and the implementation. The spec says a declaration should error if not explicitly set, but the implementation just initializes them to something that is likely to error. Like NaN for floats which I would have thought would have been 0 based on prior experiences with other languages.

Another one of my pet peeves in D.  Though this post (http://forum.dlang.org/post/tcldaatzzbhjoamnvniu@forum.dlang.org) made me realize we might be able to do something about that.

> +- Unicode support is good. Although I think D's string type should have probably been utf16 by default. Especially considering the utf module states:
>
> "UTF character support is restricted to '\u0000' <= character <= '\U0010FFFF'."

See http://utf8everywhere.org/

> + Templates seem powerful. I've only fiddled thus far, but I don't think I've quite comprehended their usefulness yet. It will probably take me some time to figure out how to wield them effectively. One thing I accidentally stumbled upon that I liked was that I could simulate inheritance in structs with them, by using the mixin keyword. That was cool, and I'm not even sure if that is what they were really meant to enable.

Templates, CTFE, and mixins are gravy! and D's the only language I know of that has this symbiotic feature set.

> So those are just some of my thoughts. Tell me why I'm wrong :P

I share much of your perspective.  Thanks for the interesting read.

Mike

On Tuesday, 28 November 2017 at 04:37:04 UTC, Michael V. Franklin wrote:
> Please submit things like this to the issue tracker.  They are very easy to fix, and if I'm aware of them, I'll probably do the work.  But, please provide a code example and
> offer a suggestion of what you would prefer it to say; it just makes things easier.>

I'd be happy to submit an issue, but I'm not quite sure I'd be the best to determine an error message (at least not this early). Mainly because I have no clue what it was yelling at me about. I only new to add static because I told people my intentions and they suggested it. I guess having a non statically marked class is a valid feature imported from Java world. I'm just not as familiar with that specific feature of Java. Therefore I have no idea what the text really had to do with anything. Maybe appending "if you meant to make a static class" would have been helpful. I fiddled with Rust a little too, and it's what they tend to do very well. Make verbose error messages.

> We're not alone:  https://youtu.be/6_xdfSVRrKo?t=353

And he was so much better at articulating it than I was. Another C# guy though. :)

On Tuesday, 28 November 2017 at 04:48:57 UTC, A Guy With an Opinion wrote:

> I'd be happy to submit an issue, but I'm not quite sure I'd be the best to determine an error message (at least not this early). Mainly because I have no clue what it was yelling at me about. I only new to add static because I told people my intentions and they suggested it. I guess having a non statically marked class is a valid feature imported from Java world.

If this was on the forum, please point me to it.  I'll see if I can understand what's going on and do something about it.

Thanks,
Mike

On Tuesday, 28 November 2017 at 05:16:54 UTC, Michael V. Franklin wrote:
> On Tuesday, 28 November 2017 at 04:48:57 UTC, A Guy With an Opinion wrote:
>
>> I'd be happy to submit an issue, but I'm not quite sure I'd be the best to determine an error message (at least not this early). Mainly because I have no clue what it was yelling at me about. I only new to add static because I told people my intentions and they suggested it. I guess having a non statically marked class is a valid feature imported from Java world.
>
> If this was on the forum, please point me to it.  I'll see if I can understand what's going on and do something about it.
>
> Thanks,
> Mike

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

On 11/27/17 10:01 PM, A Guy With an Opinion wrote:
> Hi,

Hi Guy, welcome, and I wanted to say I was saying "me too" while reading much of your post. I worked on a C# based client/server for about 5 years, and the biggest thing I agree with you on is the generic programming. I was also using D at the time, and using generics felt like eating a superbly under-baked cake.

A few points:

> - Some of the errors from DMD are a little strange. I don't want to crap on this too much, because for the most part it's fine. However occasionally it throws errors I still can't really work out why THAT is the error it gave me. Some of you may have saw my question in the "Learn" forum about not knowing to use static in an embedded class, but the error was the following:
> 
> Error: 'this' is only defined in non-static member functions

Yes, this is simply a bad error message. Many of our bad error messages come from something called "lowering", where one piece of code is converted to another piece of code, and then the error message happens on the converted code. So essentially you are getting errors on code you didn't write!

They are more difficult to fix, since we can't change the real error message (it applies to real code as well), and the code that generated the lowered code is decoupled from the error. I think this is one of those cases.

> I'd say the errors so far are above some of the cryptic stuff C++ can throw at you (however, I haven't delved that deeply into D templates yet, so don't hold me to this yet), but in terms of quality I'd put it somewhere between C# and C++ in quality. With C# being the ideal.

Once you use templates a lot, the error messages explode in cryptology :) But generally, you can get the gist of your errors if you can decipher half-way the mangling.

> - ...however, where are all of the collections? No Queue? No Stack? No HashTable? I've read that it's not a big focus because some of the built in stuff *can* behave like those things. The C# project I'm porting utilizes queues and a specifically C#'s Dictionary<> quite a bit, so I'm not looking forward to having to hand roll my own or use something that aren't fundamentally them. This is definitely the biggest negative I've come across. I want a queue, not something that *can* behave as a queue. I definitely expected more from a language that is this old.

I haven't touched this in years, but it should still work pretty well (if you try it and it doesn't compile for some reason, please submit an issue there): https://github.com/schveiguy/dcollections

It has more of a Java/C# feel than other libraries, including an interface hierarchy.

That being said, Queue is just so easy to implement given a linked list, I never bothered :)

> + Unit tests. Finally built in unit tests. Enough said here. If the lack of collections was the biggest negative, this is the biggest positive. I would like to enable them at build time if possible though.

+1000

About the running of unit tests at build time, many people version their main function like this:

version(unittest) void main() {}
else

int main(string[] args) // real declaration
{ ... }

This way, when you build with -unittest, you only run unit tests, and exit immediately. So enabling them at build time is quite easy.

> - Attributes. I had another post in the Learn forum about attributes which was unfortunate. At first I was excited because it seems like on the surface it would help me write better code, but it gets a little tedious and tiresome to have to remember to decorate code with them. It seems like most of them should have been the defaults. I would have preferred if the compiler helped me and reminded me. I asked if there was a way to enforce them globally, which I guess there is, but I guess there's also not a way to turn some of them off afterwards. A bit unfortunate. But at least I can see some solutions to this.

If you are using more templates (and I use them the more I write D code), you will not have this problem. Templates infer almost all attributes.

> - Immutable. I'm not sure I fully understand it. On the surface it seemed like const but transitive. I tried having a method return an immutable value, but when I used it in my unit test I got some weird errors about objects not being able to return immutable (I forget the exact error...apologies). I refactored to use const, and it all worked as I expected, but I don't get why the immutable didn't work. I was returning a value type, so I don't see why passing in assert(object.errorCount == 0) would have triggered errors. But it did. 

This is likely because of Adam's suggestion -- you were incorrectly declaring a function that returned an immutable like this:

immutable T foo();

Where the immutable *doesn't* apply to the return value, but to the function itself. immutable applied to a function is really applying immutable to the 'this' reference.

> + Templates seem powerful. I've only fiddled thus far, but I don't think I've quite comprehended their usefulness yet. It will probably take me some time to figure out how to wield them effectively. One thing I accidentally stumbled upon that I liked was that I could simulate inheritance in structs with them, by using the mixin keyword. That was cool, and I'm not even sure if that is what they were really meant to enable.

Templates and generative programming is what hooks you on D. You will be spoiled when you work on other languages :)

-Steve

On Tuesday, 28 November 2017 at 03:01:33 UTC, A Guy With an Opinion wrote:
> So those are just some of my thoughts. Tell me why I'm wrong :P

You are not supposed to come to this forum with well-balanced opinions and reasonable arguments. It's not colourful enough to be heard!

Instead make a dent in the universe. Prepare your most impactful, most offensive statements to push your personal agenda of what your own system programming language would be like, if you had the stamina. Use doubtful analogies and references to languages with wildly different goals than D. Prepare to abuse the volunteers, and say how much you would dare to use D, if only it would do "just this one obvious change". Having this feature would make the BlobTech industry switch to D overnight!

And you haven't asked for any new feature, especially no new _syntax_ were demanded! I don't know, find anything:

"It would be nice to have a shortcut syntax for when you wan't to add zero. Writing 0 + x is cumbersome, when +x would do it. It has the nice benefit or unifying unary and binary operators, and thus leads to a simplified implementation."

Do you realize the dangers of looking satisfied?

On Tuesday, 28 November 2017 at 13:17:16 UTC, Steven Schveighoffer wrote:
> This is likely because of Adam's suggestion -- you were incorrectly declaring a function that returned an immutable like this:

> immutable T foo();
>
> -Steve

That's exactly what it was I think. As I stated before, I tried to do immutable(T) but I was drowning in errors at that point that I just took a step back. I'll try to refactor it back to using immutable. I just honestly didn't quite know what I was doing obviously.

On Tuesday, 28 November 2017 at 13:17:16 UTC, Steven Schveighoffer wrote:
> https://github.com/schveiguy/dcollections

On Tuesday, 28 November 2017 at 03:37:26 UTC, rikki cattermole wrote:
> https://github.com/economicmodeling/containers

Thanks. I'll check both out. It's not that I don't want to write them, it's just I don't want to stop what I'm doing when I need them and write them. It takes me out of my thought process.

On Tuesday, 28 November 2017 at 03:01:33 UTC, A Guy With an Opinion wrote:
> - Attributes. I had another post in the Learn forum about attributes which was unfortunate. At first I was excited because it seems like on the surface it would help me write better code, but it gets a little tedious and tiresome to have to remember to decorate code with them. It seems like most of them should have been the defaults. I would have preferred if the compiler helped me and reminded me. I asked if there was a way to enforce them globally, which I guess there is, but I guess there's also not a way to turn some of them off afterwards. A bit unfortunate. But at least I can see some solutions to this.

Attributes were one of my biggest hurdles when working on my own projects. For example, it's a huge PITA when you have to add a debug writeln deep down in your call stack, and it ends up violating a bunch of function attributes further up. Thankfully, wrapping statements in debug {} allows you to ignore pure and @safe violations in that code if you compile with the flag -debug.

Also, you can apply attributes to your whole project by adding them to main

void main(string[] args) @safe {}

Although this isn't recommended, as almost no program can be completely safe. You can do it on a per-file basis by putting the attributes at the top like so

@safe:
pure: