August 21, 2018 Re: Friends don't let friends use inout with scope and -dip1000 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On 8/21/18 9:42 AM, Kagamin wrote:
> ....except for templated functions:
>
> int[] escape(scope int[] r)
> {
> return r; //error, can't return scoped argument
> }
>
> int[] escape(return int[] r)
> {
> return r; //ok, just as planned
> }
>
> int[] escape(return scope int[] r)
> {
> return r; //ok, `return scope` reduced to just `return`
> }
>
> int[] escape(T)(scope int[] r)
> {
> return r; //ok! `scope` silently promoted to `return`
> }
>
> You can't have strictly scoped parameter in a templated function - it's silently promoted to return parameter. Is this intended?
I would guess it's no different than other inferred attributes. I would also guess that it only gets promoted to a return parameter if it's actually returned.
As long as the *result* is scoped like the parameter. In the case of the OP in this thread, there is definitely a problem with inout and the connection to the return value.
-Steve
|
August 21, 2018 Re: Friends don't let friends use inout with scope and -dip1000 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nicholas Wilson | On Tuesday, 21 August 2018 at 11:28:39 UTC, Nicholas Wilson wrote:
> On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote:
>> On Tuesday, 21 August 2018 at 09:50:46 UTC, Atila Neves wrote:
>>> On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote:
>>>> On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote:
>>>>> On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote:
>>>>> Error: address of variable s assigned to gInt with longer lifetime
>>>>
>>>> Looks safe to me.
>>>
>>> With dmd 2.081.2 on Arch Linux, the code above compiles with no error message.
>>
>> Never mind, I forgot to use -dip1000. Ok, cool, so _why_ does it work as intended now? Also, if I have to remember to annotate correctly, surely this is a massive hole in @safe dip1000?
>
> MyStruct is not a template, I presume `return` would get inferred if it was. But yeah that is annoying.
At the very least then it should fail to compile if I don't add the relevant annotation, not silently accept buggy code that isn't memory safe but somehow _is_ `@safe`.
That's the whole point of -dip1000, no? If I get around it by forgetting something, it's not going to work.
|
August 21, 2018 Re: Friends don't let friends use inout with scope and -dip1000 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Tuesday, 21 August 2018 at 13:42:31 UTC, Kagamin wrote: > int[] escape(scope int[] r) > { > return r; //error, can't return scoped argument > } ... > int[] escape(T)(scope int[] r) > { > return r; //ok! `scope` silently promoted to `return` > } > > You can't have strictly scoped parameter in a templated function - it's silently promoted to return parameter. Is this intended? I filed a similar bug (it uses return type inference rather than a template). Walter closed it as invalid: https://issues.dlang.org/show_bug.cgi?id=17362 |
August 22, 2018 Re: Friends don't let friends use inout with scope and -dip1000 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Tuesday, 21 August 2018 at 14:04:15 UTC, Steven Schveighoffer wrote:
> I would guess it's no different than other inferred attributes. I would also guess that it only gets promoted to a return parameter if it's actually returned.
If we can't have properly typed parameters, it feels like it has potential to prevent some patterns.
This prevents automatic scope promotion:
template escape(T)
{
int[] escape1(scope int[] r)
{
return r;
}
alias escape=escape1;
}
|
August 22, 2018 Re: Friends don't let friends use inout with scope and -dip1000 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On 8/22/18 4:17 AM, Kagamin wrote: > On Tuesday, 21 August 2018 at 14:04:15 UTC, Steven Schveighoffer wrote: >> I would guess it's no different than other inferred attributes. I would also guess that it only gets promoted to a return parameter if it's actually returned. > > If we can't have properly typed parameters, it feels like it has potential to prevent some patterns. But scope is not part of the type, nor is return. One of my biggest concerns about dip1000 is that the "scope-ness" or "return-ness" of a variable is hidden from the type system. It's just the compiler doing flow analysis and throwing you an error when it can't work the thing out. I'm more worried about not being able to express the flow in a way that the compiler understands, and having it complain about things that are actually safe. > > This prevents automatic scope promotion: > > template escape(T) > { > int[] escape1(scope int[] r) > { > return r; > } > alias escape=escape1; > } But that's not valid dip1000 code. If you call it, it should give a compiler error (r *does* escape its scope). -Steve |
August 22, 2018 Re: Friends don't let friends use inout with scope and -dip1000 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Wednesday, 22 August 2018 at 14:05:10 UTC, Steven Schveighoffer wrote:
> But that's not valid dip1000 code. If you call it, it should give a compiler error (r *does* escape its scope).
When I complained about C++ safety to my C++ programmer colleague, he told me that the compiler just compiles what's written. On one hand I can understand what he wanted to say, but the wording is still hilarious and fits C++ very well. What I like in D is that if it's written doesn't mean that it will compile: invalid code should be rejected.
|
Copyright © 1999-2021 by the D Language Foundation