Don't try to convert string if it's already an LLWString; also remove orphaned method declarations

[Ansariel]

No description provided.

[Nicky-D]

Thanks for that, I wasn't able to react fast enough on #2729 (no complaint at all about the fast turnout time, they are much appreciated!).

Regarding the conversion: I am (maybe wrongly) under the impression that ll_convert_impl is basically a no-op in those cases.

template<typename T>
struct ll_convert_impl<T, T>
{
    T operator()(const T& in) const { return in; }
};

// simple construction from char*
template<typename T>
struct ll_convert_impl<T, const typename T::value_type*>
{
    T operator()(const typename T::value_type* in) const { return { in }; }
};

[nat-goodspeed]

Certainly we want ll_convert<T>(const T& in) to be a no-op. Do you observe otherwise?

The design intent is to be able to use ll_convert() to adapt any conventional viewer string type to the intended target type, without having to break out special cases -- even if the source type is already the target type.

[Ansariel]

You are still having to call the operator and shuffle the strings around - unless the compiler somehow optimizes it away. This change prevents that by doing the check at compile time and omitting the no-op call of the operator.

[nat-goodspeed]

The key question seems to be whether there's zero runtime cost to a same-type ll_convert(). If that turns out not to be true, my preferred fix would be to try to eliminate that runtime cost.

I'm happy we now have if constexpr; I'd hate to have to use std::enable_if tricks to effect the same thing. My problem with the proposed change is that it suggests propagating the same logic everywhere the source might be the same type as the target. I'd rather have a 10-character function call than a 4-line idiom.

[Ansariel]

Closing this PR in favor of #2734

[nat-goodspeed]

Hmm @Ansariel I didn't delete any of the obsolete LLTextEditor method declarations as you did. Do you want to reopen this PR without the if constexpr, or should I delete those separately?