On Tuesday, 28 November 2017 at 16:14:52 UTC, Jack Stouffer wrote:
> You can do it on a per-file basis by putting the attributes at the top like so

That doesn't quite work since it doesn't descend into aggregates. And you can't turn most them off.

On Tuesday, 28 November 2017 at 04:17:18 UTC, A Guy With an Opinion wrote:
> On Tuesday, 28 November 2017 at 04:12:14 UTC, ketmar wrote:
>> A Guy With an Opinion wrote:
>>
>>> That is true, but I'm still unconvinced that making the person's program likely to error is better than initializing a number to 0. Zero is such a fundamental default for so many things. And it would be consistent with the other number types.
>> basically, default initializers aren't meant to give a "usable value", they meant to give a *defined* value, so we don't have UB. that is, just initialize your variables explicitly, don't rely on defaults. writing:
>>
>> 	int a;
>> 	a += 42;
>>
>> is still bad code, even if you're know that `a` is guaranteed to be zero.
>>
>> 	int a = 0;
>> 	a += 42;
>>
>> is the "right" way to write it.
>>
>> if you'll look at default values from this PoV, you'll see that NaN has more sense that zero. if there was a NaN for ints, ints would be inited with it too. ;-)
>
> Eh...I still don't agree. I think C and C++ just gave that style of coding a bad rap due to the undefined behavior. But the issue is it was undefined behavior. A lot of language features aim to make things well defined and have less verbose representations. Once a language matures that's what a big portion of their newer features become. Less verbose shortcuts of commonly done things. I agree it's important that it's well defined, I'm just thinking it should be a value that someone actually wants some notable fraction of the time. Not something no one wants ever.
>
> I could be persuaded, but so far I'm not drinking the koolaid on that. It's not the end of the world, I was just confused when my float was NaN.

Just a little anecdote of a maintainer of a legacy project in C. My predecessors in that project had the habit of systematically initialize any auto declared variable at the beginning of a function. The code base that was initiated in the early '90s and written by people who were typical BASIC programmer, so the consequence of it was that functions were very often hundreds of lines long and they all started with a lot of declarations.
In the years of reviewing that code, and I was really surprised by that, was how often I found bugs because the variables had been wrongly initialised. By initialising with 0 or NULL, the data flow pass was essentially suppressed at the start so that it could not detect when variables were used before they had been properly populated with the right values the functionality required. The thing with these kind of bugs was that they were very subtle.

To make it short, 0 is an arbitrary number that often is the right value but when it isn't, it can be a pain to detect that it was the wrong value.

On Tuesday, 28 November 2017 at 04:19:40 UTC, A Guy With an Opinion wrote:
> On Tuesday, 28 November 2017 at 04:17:18 UTC, A Guy With an Opinion wrote:
>> [...]
>
> Also, C and C++ didn't just have undefined behavior, sometimes it has inconsistent behavior. Sometimes int a; is actually set to 0.
It's only auto variables that are undefined. statics and code unit (aka globals) are defined.

On 2017-11-28 17:24, Adam D. Ruppe wrote:

> That doesn't quite work since it doesn't descend into aggregates. And you can't turn most them off.

And if your project is a library.

-- 
/Jacob Carlborg

On Tuesday, 28 November 2017 at 16:24:56 UTC, Adam D. Ruppe wrote:
>
> That doesn't quite work since it doesn't descend into aggregates. And you can't turn most them off.

I take it adding those inverse attributes is no trivial thing?

On Tuesday, 28 November 2017 at 19:34:27 UTC, A Guy With an Opinion wrote:

> I take it adding those inverse attributes is no trivial thing?

It would require a DIP: https://github.com/dlang/DIPs

This DIP is related (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md) but I don't know what's happening with it.

Mike

On Tuesday, 28 November 2017 at 19:34:27 UTC, A Guy With an Opinion wrote:
> I take it adding those inverse attributes is no trivial thing?

Technically, it is extremely trivial.

Politically, that's a different matter. There's been arguments before about the words or the syntax (is it "@gc" or "@nogc(false)", for example? tbh i think the latter is kinda elegant, but the former works too, i just want something that work) and the process (so much paperwork!) and all kinds of nonsense.

On Tuesday, 28 November 2017 at 19:39:19 UTC, Michael V. Franklin wrote:

> This DIP is related (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md) but I don't know what's happening with it.
>

It's awaiting formal review. I'll move it forward when the formal review queue clears out a bit.

On Tuesday, 28 November 2017 at 22:08:48 UTC, Mike Parker wrote:
> On Tuesday, 28 November 2017 at 19:39:19 UTC, Michael V. Franklin wrote:
>
>> This DIP is related (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md) but I don't know what's happening with it.
>>
>
> It's awaiting formal review. I'll move it forward when the formal review queue clears out a bit.

How well does phobos play with it? I'm finding, for instance, it's not playing too well with nothrow. Things throw that I don't understand why.

On 11/27/2017 7:01 PM, A Guy With an Opinion wrote:
> +- 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'."
> 
> Seems like the natural fit for me. Plus for the vast majority of use cases I am pretty guaranteed a char = codepoint. Not the biggest issue in the world and maybe I'm just being overly critical here.

Sooner or later your code will exhibit bugs if it assumes that char==codepoint with UTF16, because of surrogate pairs.

https://stackoverflow.com/questions/5903008/what-is-a-surrogate-pair-in-java

As far as I can tell, pretty much the only users of UTF16 are Windows programs. Everyone else uses UTF8 or UCS32.

I recommend using UTF8.