On Friday, 9 February 2018 at 13:47:51 UTC, Atila Neves wrote:
> On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky
>>
>> And yes, things like "inout", "auto ref" or whatever, and such, strike me as indicative of more fundamental design flaws. (Not "flaw" in the sence of "mistakes" necessarily, but "flaw" in the sence of "there must be a better way to design these things...")
>>
>> [...]
>
> Yeah, something like traits in Rust or typeclasses in Haskell would be a lot better. Fortunately, one can kinda-sorta get there with a library solution. Check out `@implements` in https://github.com/atilaneves/concepts
>

I'm confused. While I get how @implements resolves the same issues as Rusts's traits, I don't see how traits resolve the same issues as inout/auto ref. My understanding is that inout and auto ref mean you don't have to write multiple versions of the relevant functions. Moreover, while one could use templates to do something similar, inout/auto ref are designed to reduce code bloat. I don't think Rust's traits can accomplish the same thing, but I'm not familiar enough with Haskell's typeclasses to know.

On Friday, 9 February 2018 at 15:09:10 UTC, Mike Parker wrote:
> On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster wrote:
>
>> const auto MAX_IN = 20;
>
> const MAX_IN = 20;
>
> The auto is superfluous and is only needed when there's no storage class or type.
>
>>
>> Others say to use enums.  It turns out enums seems to be the best, as they don't create a symbol in the object file, but const auto does.
>
> If you need to take the address of a constant, use immutable or const (doesn't really matter, but I prefer immutable). If you don't need the address, use enum.

Why not static immutable?

On Friday, 9 February 2018 at 15:03:02 UTC, Adam D. Ruppe wrote:
> On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster wrote:
>> The docs say using "private" will keep the symbol out of the file, but that is not true.
>> https://dlang.org/spec/attribute.html#static
>
> That sentence isn't well written since D's private and C's static
>  are different... what D's private does is make the symbol invisible to other D files; when you import the module, it doesn't import the private names so it acts like they don't exist.
>
> But they do still exist in the object file. I'm pretty sure C's statics do too actually just without an exported name...

Yes, C's "const static" will still create a symbol in the object file.  I just checked with gcc5, and it creates a local readonly symbol "r".

My point is that in D, the docs say "private" will keep the definition out of the object file.  I think you'll have to agree that it's at least confusing.

On Friday, 9 February 2018 at 15:05:05 UTC, Jonathan M Davis wrote:
>
> The memory model needs to be properly defined like C++ finally did. It works without that, but as I understand it, it's technically relying too much on implementation-defined behavior.
> [snip]


Thanks for the write-up!

On Friday, 9 February 2018 at 15:29:52 UTC, Ralph Doncaster wrote:
> My point is that in D, the docs say "private" will keep the definition out of the object file.  I think you'll have to agree that it's at least confusing.

The exact quote is: "Static does not have the additional C meaning of being local to a file. Use the private attribute in D to achieve that."

It doesn't say anything about object files.

On Friday, 9 February 2018 at 15:05:05 UTC, Jonathan M Davis wrote:
> [...]
> The reality of the matter is that shared is _supposed_ to result in a bunch of compilation errors when you try to do stuff to it. You're supposed to either use atomics to mutate a shared object or protect it with a mutex and temporarily cast away shared so that you can actually do stuff with it. You're really not supposed to do much with a shared object while it's shared, and a lot of folks don't understand that.
> [...]
> - Jonathan M Davis

Time to write an article/tutorial about this! Did I miss it?

Andrea

On Friday, 9 February 2018 at 15:27:18 UTC, Andrea Fontana wrote:

>> If you need to take the address of a constant, use immutable or const (doesn't really matter, but I prefer immutable). If you don't need the address, use enum.
>
> Why not static immutable?

For global scope? static has no effect there as far as I know. Looking at the ASM output on run.dlang.io, I see no difference between the two:

static immutable foo = 10;
immutable bar = 20;

LAT	group	
;File = onlineapp.d
	public	immutable(int) onlineapp.foo
	public	immutable(int) onlineapp.bar

...
                mov	EDI,0Ah
		call	  @safe void std.stdio.writeln!(immutable(int)).writeln(immutable(int))@PLT32
		mov	EDI,014h
		call	  @safe void std.stdio.writeln!(immutable(int)).writeln(immutable(int))@PLT32

On Friday, 9 February 2018 at 15:09:10 UTC, Mike Parker wrote:
> On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster wrote:
>
>> const auto MAX_IN = 20;
>
> const MAX_IN = 20;
>
> The auto is superfluous and is only needed when there's no storage class or type.
>
>>
>> Others say to use enums.  It turns out enums seems to be the best, as they don't create a symbol in the object file, but const auto does.
>
> If you need to take the address of a constant, use immutable or const (doesn't really matter, but I prefer immutable). If you don't need the address, use enum.

I think you are proving my point.  You say there is no difference between:
const MAX_IN = 20;
vs
immutable MAX_IN = 20;

So now I have to try both, and look at the generated code to be sure.
p.s. I prefer const since it is easier for C/C++ coders to understand.  Using immutable invites the coder to go down the whole rat hole of trying to understand how is it different than const.

On Friday, 9 February 2018 at 15:37:12 UTC, Ralph Doncaster wrote:


> I think you are proving my point.  You say there is no difference between:
> const MAX_IN = 20;
> vs
> immutable MAX_IN = 20;
>
> So now I have to try both, and look at the generated code to be sure.

Or read the docs:

https://dlang.org/spec/const3.html

> p.s. I prefer const since it is easier for C/C++ coders to understand.  Using immutable invites the coder to go down the whole rat hole of trying to understand how is it different than const.

It's not a rathole. The document page above explains the differences rather well. They only happen to be identical when initialized with compile-time constants.

On Friday, 9 February 2018 at 15:35:38 UTC, Mike Parker wrote:
> On Friday, 9 February 2018 at 15:27:18 UTC, Andrea Fontana wrote:
>
>>> If you need to take the address of a constant, use immutable or const (doesn't really matter, but I prefer immutable). If you don't need the address, use enum.
>>
>> Why not static immutable?
>
> For global scope? static has no effect there as far as I know. Looking at the ASM output on run.dlang.io, I see no difference between the two:
>
> static immutable foo = 10;
> immutable bar = 20;
>
> LAT	group	
> ;File = onlineapp.d
> 	public	immutable(int) onlineapp.foo
> 	public	immutable(int) onlineapp.bar
>
> ...
>                 mov	EDI,0Ah
> 		call	  @safe void std.stdio.writeln!(immutable(int)).writeln(immutable(int))@PLT32
> 		mov	EDI,014h
> 		call	  @safe void std.stdio.writeln!(immutable(int)).writeln(immutable(int))@PLT32

If I'm right on classes/structs static immutable != immutable. So if you need to replace enum in those cases too, static immutable works fine everywhere. Right?