January 30, 2017
On Monday, 30 January 2017 at 11:32:11 UTC, Walter Bright wrote:
> I'd rather do one thing at a time.

+1

And it won't be too difficult to search-and-replace `const scope` with `in` once things has stabilized and all the corner cases have been sorted out.

Thanks for making D more safe, Walter. D really needs it in the competition with Rust.

Once things have stabilized we really need to announce this work and highlight its developer productivity compared to Rust.
January 30, 2017
On Monday, 30 January 2017 at 13:57:10 UTC, Adam D. Ruppe wrote:
> On Monday, 30 January 2017 at 00:26:27 UTC, Walter Bright wrote:
>> I was afraid that by checking it, too much code would break.
>
> Code that was using it improperly was *already* broken. Now, the compiler will simply tell them, at compile time, why instead of letting it silently accept undefined behavior.

Well, it's a trade-off. Some people would rather their project with potentially broken code does not stop compiling because they upgraded their compiler.

Although I guess you could solve this by having -dip1000 emit only warnings and no error until the adaptation period had passed.
January 30, 2017
On Monday, 30 January 2017 at 12:08:06 UTC, Olivier FAURE wrote:
> On Monday, 30 January 2017 at 06:38:11 UTC, Jonathan M Davis wrote:
>> Personally, I think that effectively having an alias for two attributes in a single attribute is a confusing design decision anyway and think that it was a mistake, but we've had folks slapping in on stuff for years with no enforcement, and flipping the switch on that would likely not be pretty.
>>
>> - Jonathan M Davis
>
> I've always thought of 'in' as a visual shorthand for "this parameter doesn't care whether you give it a deep copy or a shallow reference", personally.

Would have been a far better definition. Why does anyone really need a shorthand attribute for two attributes that could be easily spelled out? You can type anything for "const  scope" while programming and then do search-and-replace. That's even trivial.

Can't we make "in" mean "const scope ref", that binds on r-values, too? Effectively, that's (similar to) what "const T&" in C++ means. It's a non-copying const view on the object. We have the longstanding problem, one must overload a function to effectively bind both l- and r-values. That is what I'd suppose to be the dual to "out".
January 30, 2017
On Monday, 30 January 2017 at 19:05:33 UTC, Q. Schroll wrote:
> Can't we make "in" mean "const scope ref", that binds on r-values, too? Effectively, that's (similar to) what "const T&" in C++ means. It's a non-copying const view on the object.

'ref' being separate from 'in' allows you to use both:

foo(in ref T x);
foo(in T* x);

However, I agree that 'in' should be the opposite of 'out' (const scope ref). Making the 'in' and 'out' keywords semantically asymmetrical just to save a few key strokes is dumb.

> We have the longstanding problem, one must overload a function to effectively bind both l- and r-values. That is what I'd suppose to be the dual to "out".

+1 on allowing rvalue to bind to 'const scope ref'...or 'in' done right.

January 30, 2017
On Monday, 30 January 2017 at 19:05:33 UTC, Q. Schroll wrote:
> Can't we make "in" mean "const scope ref", that binds on r-values, too? Effectively, that's (similar to) what "const T&" in C++ means. It's a non-copying const view on the object. We have the longstanding problem, one must overload a function to effectively bind both l- and r-values. That is what I'd suppose to be the dual to "out".

+1000, I really love this proposal; I *hate* that this point is still missing in D in 2017.
It shouldn't even break existing code using `in` (but obviously the ABI) just because now a pointer to a const instance is passed instead of making a const copy.

Generic stuff:          void foo(in T arg)    // const scope ref => safe `const T&`
By-value optimizations: void foo(const T arg)

I love it.
January 31, 2017
On Monday, 30 January 2017 at 00:26:27 UTC, Walter Bright wrote:
> On 1/29/2017 3:50 AM, Nordlöw wrote:
>> Why is `in` no longer the same as `const scope`?
>
> Because it was unchecked and largely unimplemented. I was afraid that by checking it, too much code would break.

Unless I'm completely missing something the documentation still says:

http://dlang.org/spec/function.html#parameters
in	equivalent to const scope
January 30, 2017
On 1/30/2017 7:06 AM, Nordlöw wrote:
> And it won't be too difficult to search-and-replace `const scope` with `in` once
> things has stabilized and all the corner cases have been sorted out.
>
> Thanks for making D more safe, Walter. D really needs it in the competition with
> Rust.

You're welcome.


> Once things have stabilized we really need to announce this work and highlight
> its developer productivity compared to Rust.

It's what I plan to talk about at DConf.
January 31, 2017
On Mon, 30 Jan 2017 19:05:33 +0000, Q. Schroll wrote:
> Would have been a far better definition. Why does anyone really need a shorthand attribute for two attributes that could be easily spelled out?

Because there was existing code thath used `in` and `scope const` was the nearest equivalent.
1 2
Next ›   Last »