+
Skip to content

Semantics for initializer lists #73

@hostilefork

Description

@hostilefork

The C interface has grown by leaps and bounds, to where it supports arbitrary splicing of values based on header layouts.

The main header file includes a few basic conversions to make the syntax nicer (e.g. just say 1020 instead of rebI(1020)). It also does some usage checking.

But the RenCpp binding aimed to bring some more power, and it's worth picking through the features to see which are interesting. One of them was this:

// ren::Block {1, {2, 3}, 4};
//
// Block is configured so that it can be constructed from
// a list of BlockLoadable<Block>, which means that every
// untyped curly braces in a Block constructor will construct
// new instances of Block.

If you were going to do that using the C binding's methods, it would look like:

REBVAL *block = rebValue("[1 [2 3] 4]");

And you can do splicing as well:

REBVAL *block = rebValue("[1 [", two, "3]", four, "]");

The syntax in RenCpp doesn't seem to be that much clearer. And since braces are used for strings, it's actually somewhat confusing.

There might (?) be a performance advantage to creating the block through a compiled call vs. letting the scanner to stack processing of "[" and "]" in the text. Although measurement might prove it's actually a disadvantage, as the scanner is optimized for this case.

Is there a higher-leverage feature that initializer-lists could be applied to in the C++ API?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载