On Sat, Jan 04, 2020 at 08:19:14PM +0100, Robert M. Münch via Digitalmars-d-learn wrote: > On 2019-12-31 21:36:56 +0000, Steven Schveighoffer said: > > > The fact that a Grapheme's return requires you keep the grapheme in > > scope for operations seems completely incorrect and dangerous IMO > > (note that operators are going to always have a ref this, even when > > called on an rvalue). So even though using ref works, I think the > > underlying issue here really is the lifetime problem. > > Thanks for all the answers, pretty enlighting even I'm not sure I get > everything 100%. > > So, what to do for now? File a bug-report? What needs to be fixed?
At a minimum, I think we should file a bug report to investigate whether Grapheme.opSlice can be implemented differently, such that we avoid this obscure referential behaviour that makes it hard to work with in complex code. I'm not sure if this is possible, but IMO we should at least investigate the possibilities. > I'm using the ref approach for now, in hope it will be OK for my > use-case, which is converting a wstring to a grapheme, alter the > array, and map it back to a wstring. Sounds like a lot of porcessing > for handling unicode text, but I don't think it gets a lot simpler > than that. [...] Unicode is a beast. Be glad that you can even do this in the first place. If I were writing this in C, I wouldn't even know where to begin! T -- No! I'm not in denial!