KMime API review

[Ingo Klöcker]

On Mittwoch, 4. Februar 2026 16:31:26 Mitteleuropäische Normalzeit Sune 
Vuorela wrote:
> On 2025-09-15, Albert Astals Cid <aacid at kde.org> wrote:
> > As requested during Akademy.
> 
> I have been toying a bit with the new API, and so far I at least have a
> couple of questions:
> 
> Content/Message:
> 
> The overload is a bit confusing I_think:
>      KMime::Headers::Subject *subject(CreatePolicy create = Create);
>      [[nodiscard]] const KMime::Headers::Subject *subject() const
> 
> if `this` is const, the function takes one optional argument, else no
> arguments.

I think you didn't write what you meant to write.

If `this` is const, the function *does not take* an argument. Otherwise, it 
takes one optional argument. This makes a lot of sense to me because you 
cannot create/add a new header to a const object. The argument-less overload 
prevents you from calling subject() with Create. Hmm, is your concern that the 
non-const overload creates a new header if called without argument while the 
const overload doesn't create a new header?

> Types:
>  At least KMime::Type::Address have a public QList member

What do you suggest? I guess one could make the member private and add a 
public inline `const QList<KMime::Type::Address> &` getter to avoid the smell 
of a public member variable and, at the same time, avoid a prohibitive 
performance penalty. Or maybe Address should simply be a struct (with one 
private member variable) instead of a class if it's supposed to be used like a 
struct (like AddrSpec is).

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20260204/acd6ca03/attachment.sig>