A new childof idea and philosophy

[Rick C. Hodgin]

In the code I write, there is a natural hierarchy of algorithms being
broken out to simplify code. However, there is information conveyed
that the compiler cannot assume without taking some big assumptions,
such as if func1() calls func2() with some parameters validated in
func1(), the compiler can't safely recognize that the parameters passed
in to func2() have already been validated, so there's no reason to
check for a NULL pointer, or something invalid.

While this doesn't prevent things from compiling, code analysis is not
possible as it should be because the compiler does not have that
information.

As such, I propose adding a new childof keyword, which will indicate
that a function is the direct child of the parent function. This will
convey information that untested parameters are assumed to have already
been tested in the calling function.

int func1(void)
{
int* p;

if ((p = populate_the_pointer()))
return func2(p);

return -1;
}

int func2(int* p) childof func1
{
// Direct use without NULL testing
*p = *p + get_step_size();
}

In this way, the compiler is able to know that func2() is designed to
be explicitly called from func1(), and is not a stand-alone function
able to be runtime-linked to some other location, or assigned as the
target of a function pointer, thereby requiring examination of the
input parameter p prior to use.

-----
In CAlive I use named_functions() along with iNamed_functions() for
child functions, and then iiNamed_functions() for those which do not
need to test those parameters. However, if inside of iiNamed_functions()
I need further discriminate and call iiNamed_functions_apples() and
also iiNamed_functions_oranges(), then there's no real way to indicate
that those ii() functions are children of any specific thing without
doing a call analysis, and even then they can still be the target of
the aformentioned function pointer or dynamic runtime linking.

By using the childof keyword, the direct ancestry of any functions can
be determined when they have been explicitly added to be that kind of
breakout code to simplify the algorithm into more manageable units.

-----
I'm curious about people's thoughts on the introduction of this new
information into C/C++?

--
Rick C. Hodgin

[Bart]

On 04/04/2019 20:20, Rick C. Hodgin wrote:

> I'm curious about people's thoughts on the introduction of this new
> information into C/C++?

What's the difference between this and nested functions?

(It is possible to implement nested functions without necessarily
sharing access to an outer function's stack-frame variables, which is
where the problem areas lie in implementation.)


int func1(void)
{
int func2(int* p)

{
// Direct use without NULL testing
*p = *p + get_step_size();

[Rick C. Hodgin]

Nested functions inherit the encapsulating parent function's scope
as well, don't they? Childof functions would be separate entities
without the parent context, and they could theoretically be the
child of multiple parents, including itself through recursion.

--
Rick C. Hodgin

[Mr Flibble]

On 04/04/2019 20:20, Rick C. Hodgin wrote:

Rather than the keyword "childof" I would prefer the keyword
"preconditions" if the idea itself wasn't so fucktarded.

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[Ian Collins]

The perils of cross posting...

Bart's example, with slight modification to use a lambda, is valid in
C++. In this case, you can choose whatever parent context you wish to
encapsulate.

int func1()
{
auto func2 = [](int* p)

{
// Direct use without NULL testing
*p = *p + get_step_size();

return 0;

};

int* p;

if ((p = populate_the_pointer()))
return func2(p);

return -1;
}

--
Ian.

[David Brown]

What does this give you, that you can't get by making "func2" a static
function? If func2 is declared static (and you haven't passed a pointer
to it to something outside the current translation unit), then the
compiler can easily see that it is only ever called from "func1". That
lets it know just as much as you could get via the "childof" feature.

(And the way to handle this in a new language would be to make all
functions effectively "static" by default, and require explicit marking
of functions to export from a module.)

[Robert Wessel]

Even if the function isn't static, there's nothing to prevent a
compiler from building specialized versions of it for local use.
Without the static, the compiler may have to build an unspecialized
version in case it is used elsewhere. In the context of (automatic)
inlining, most big compilers do that sort of thing already.