What type does byGrapheme() return?

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Dec 31 19:58:52 UTC 2019


On Tue, Dec 31, 2019 at 09:33:14AM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 12/30/19 6:31 PM, H. S. Teoh wrote:
> > On Mon, Dec 30, 2019 at 03:09:58PM -0800, H. S. Teoh via Digitalmars-d-learn wrote:
[...]
> > Haha, it's actually right there in the Grapheme docs for the opSlice
> > overloads:
> > 
> >          Random-access range over Grapheme's $(CHARACTERS).
> > 
> >          Warning: Invalidates when this Grapheme leaves the scope,
> >          attempts to use it then would lead to memory corruption.
> > 
> > Looks like when you use .map over the Grapheme, it gets copied into
> > a temporary, which gets invalidated when map.front returns.
> > Somewhere we're missing a 'scope' qualifier...
[...]
> Then the original example should be fixable by putting "ref" in for
> all the lambdas.
> 
> But this is kind of disturbing. Why does the grapheme do this? The
> original data is not scoped.

Honestly I have no idea, but glancing at the code in std.uni reveals
that the returned slice is actually a wrapper object that contains a
pointer to the parent Grapheme object.  So if the parent was a
temporary and goes out of scope before the wrapper does, we're left with
a dangling pointer.


> e.g.:
> 
> writeln(" Text = ", gr1.map!((ref g) => g[]).joiner.to!string);
[...]

Unfortunately this doesn't work. Somehow the ref parameter doesn't match
whatever it is std.algorithm.map is trying to pass to it.


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill


More information about the Digitalmars-d-learn mailing list