| |
 | Posted by Timon Gehr
in reply to Manu |  Permalink Reply |
|
Timon Gehr 
| On 12/9/24 07:47, Manu wrote:
> On Mon, 9 Dec 2024 at 01:51, Timon Gehr via Digitalmars-d <digitalmars- d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
> On 12/8/24 06:54, Manu wrote:
> > Here's the stupidest idea ever: expand inout to take an argument...
> >
> > void parseThings(string s, void delegate(Thing) inout(nothrow)
> > inout(@nogc) sink) inout(nothrow) inout(@nogc)
> > {
> > //...
> > sink(Thing());
> > //...
> > }
> > ...
>
> Issue with this is you will still not know which `inout`s match up.
> This
> is already an issue with the existing `inout`, which just arbitrarily
> selects a convention. In particular, it does not really work with
> higher-order functions the way you'd need it to here.
>
>
> Yes, this is obviously an issue, and we have it in D comprehensively; it's the main issue with our 'safe' stuff too; where rust has explicit lifetime attribution... it's essentially the same problem all round; it needs tags that specify things which are associated.
> In lieu of that though, I would say, if there are multiple things marked inout(...) in the way I proposed, you would assume the most pessimistic from the set of possibilities is supplied.
>
> void inheritAttribs(string s, void delegate() inout(nothrow) inout(@nogc) fun_1, void delegate() inout(nothrow) inout(@nogc) fun_2) inout(nothrow) inout(@nogc)
> {
> //...
> fun_1();
> fun_2();
> //...
> }
>
> In this case, `inheritAttribs` would only be nothrow in the event BOTH fun_1 and fun_2 are nothrow, likewise for nogc...
> ...
Well, this is one limitation, but the `inout` on the delegate does not even match up with the `inout` on `inheritAttribs` those are already different.
This does not compile;
```d
inout(int)* foo(inout(int)* delegate()inout dg,inout(int)* x){
return x;
}
void main(){
const(int)* delegate()const dg;
const(int)* x;
foo(dg,x); // error
}
```
It seems at least this would need to work.
`inout` is very confusing because different `inout` annotations can get conflated or not conflated. It's also the main reason why the implementation is unsound, it's not done consistently during type checking.
>
> > Surely people have had better ideas? But you get the point, and
> this is
> > basically essential to make the 'sink' pattern work at all in D.
> >
> > No, no templates; it's not right to generate multiple copies of
> identical functions just because something it CALLS would transfer
> an attribute. The function itself is identical no matter the state
> of any attribute transference, and so this isn't a template problem;
> it's a pattern matching problem.
>
> Well, it can be seen as a homogeneous vs heterogeneous compilation
> problem. The attributes can still act a bit like template parameters,
> but only one instance must be created that works for all of them. It's
> sometimes called parametric polymorphism.
>
>
> Right. Do you have examples of this from other languages and how it's expressed? Lifetime's in Rust are the obvious benchmark, but I don't see any evidence that D has a taste for this sort of thing.
> ...
Well, Java, C#, Scala support homogeneous compilation in their generics.
In Haskell everything is polymorphic by default with implicit universal quantification over lower-case type parameters.
> I do think that inout could work for all attributes the same as inout does for const (with the same limitations).
Well, as I showed above, those limitations are kind of fatal for your use case.
> You could see `inout` as shorthand for `inout(const)` under my suggestion.
> Obviously it must enforce the most restrictive implementation inside the code; my function `inheritAttribs` above must be nothrow and nogc internally, but externally it would allow a mapping from one of the 'input' attributes to the 'output' attribute in a non-templated way.
`inout` also interacts with `immutable`, not only `const`.
|
