structure defined in function parameter

[PavelVozenilek]

This is proposal to reduce number of named top level structures, thus diminishing the potential for name clashes and the urge to make top level names more unique.

It could look like:

func void foo(
   struct {  int i;  int j; } param1, // parameter passed by value
   struct { float x; float y; }* param2  // parameter passed by pointer
  )
{
  ...
}

These structures would be visually tied to functions, reducing the temptation to "reuse" them for unintended purposes.

---

They could be referred using the function name:

func void bar()
{
  foo.param1 p1;
  p1.i = ...
  foo.param2 p2;
  p2.x = ...
  foo(p1, &p2);
}

---

What are the advantages?

• Global (or module) namespace is less polluted.
• The name gives hint where it is supposed to belong. Such a tie is much stronger than module prefix or namespace.
• Merging type name and parameter name reduces funny tricks like: void foo(bar* bar_) { }
• Misuse of the name in wrong context is less likely.
• The name could be shorter.
• It is easier to grok. If you see a top level structure, there's little clue where it could be used.

---

Default parameters should be possible:

func void foo( struct { int i = 1; int j = 10; } param) {...}

"Inline" struct creation should be possible:

func void foo( struct { int i; int j; } param1, struct { float x, float y;}* param2) {...}

void bar()
{
  foo({i = 1; j = 2}, &{1.0;, 2.2;}};
}

---

An advanced feature, requiring compiler support could be deduction of the full struct name:

func void foo(struct {  int i;  int j; } param) {...}

func void bar()
{
 // Here the struct type name is NOT prefixed with function. 
  // But since it is used as parameter, the compiler may deduce this. 
  // There would be no ambiguity and IMO no confusion. 
  // Everything is in one place, easy to see.
  param p; 
  p.i = ...

  foo(p);
}

[lerno]

I thought of it, but it requires switching to structural typing or adding type inferrence or having tuple unpacking. Couldn't make a convincing case for it for c2lang, so adding it to C3 would need much greater benefit than detailed above.

A great downside to inline struct definitions is that it greatly increases the clutter of the function signature.

[PavelVozenilek]

I do not think it needs structural typing (as a new feature available in the whole language).

It is to clutter the function or to clutter the top level.

[lerno]

Better clutter the top level.

[PavelVozenilek]

There's yet another option:

struct foo.param1
{
  int i;
  int j;
}

struct foo.param2
{
  float x;
  float y;
}

func void foo(param1, &param2)
{
  ...
}

where the parameters types have to be placed just before the function and in the proper order.

[lerno]

I don't see the advantage of that as opposed to doing it the regular way with structs?

[lerno]

A more useful idea might be to structural typing for anonymous struct parameters:

struct Vec2 {
  int x;
  int y;
}
struct IntTuple {
   int a;
   int b;
}
func struct { int x; int y; } get_coordinates() { ... }
func void set_coordinates(struct { int i; int j; } coord) { ... }
....
IntTuple tuple = get_coordinates();
Vec2 vec = get_coordinates();
IntTuple tuple2 = { 1, 1 };
Vec2 vec2 = { 2, 1 };
set_coordinates(tuple2);
set_coordinates(vec2);

[PavelVozenilek]

The advantage is less global names to invent. It also gives some hint where the structure is supposed to be used.

---

Reply to: https://github.com/c3lang/c3docs/issues/9#issuecomment-530752686

The advantage of structural typing IMO is that it reduces mutual dependency between modules.

In: func_from_module_B(&sruct_from_module_A); module A needs to import module B (to call the function) and module B need to import module A for the parameter.

If there are no explicit imports, this need to eliminate dependencies is not that urgent.

[lerno]

Status for this:

1. Structural subtyping will likely happen, this will subsume what's required by this feature request.

So this will be a thing:

func void set_coordinates(struct { int i; int j; } coord) { ... }

2. Named parameter calls can be used when clarity is required.

E.g.

func void foo(int i, int j) { ... }
foo(i = 1, j = 20);

This should cover the use cases in this feature suggestion, so unless there are any additional arguments for the above format that hasn't already been discussed I think this could be closed?

[lerno]

No further arguments seems to be forthcoming, so I'll reject this.