Go intercompatibility with colons in arguments

[spoohie]

Just an open question, but are colons in definitions really necessary? Shouldn't we be striving for nice Go <-> Dingo compatibility?

func divide(a: int, b: int) Result {...}

could be simply

func divide(a int, b int) Result {...}

These colons add nothing in the long run in my opinion. The comparison between Typescript and Dingo that prevails a lot in the description should be the standard we should be striving for I believe. That means: ideally Go code should be also valid Dingo code. In case of adding colons (or any other discrepancies like "->" in return statement definition for that matter) should be avoided.

Also: README.md is super long and smells with AI generation a lot, I've been trying to read through the docs and also forums online and there's been a lot of feedback suggesting that AI-powered descriptions are kinda repulsive to the community.

Besides that it's a great piece of work and I've been super inspired by it for the last couple of days. I'll try to dig into it more and even try to carve out some spare time to help and contribute! Good work!

[dingo-reviewer]

@spoohie You're actually right, and more right than you might realize — Dingo already uses Go-style parameter syntax in practice. If you look at the actual .dingo files (e.g., examples/07_tuples/geometry.dingo), you'll see func ParseCoordinates(input string) with no colons.

The README is the problem here. It shows func divide(a: int, b: int) -> Result<...> syntax that doesn't match the real implementation. Colons and -> only exist in lambda syntax (|x: int| -> int { ... }), which is a different context. Regular functions use pure Go signatures.

tl;dr:

• Regular functions: Go-compatible syntax (no colons, no arrows) ✅
• Lambdas: use colons/arrows for type annotations since they're a new syntax anyway
• README: needs a rewrite to match reality — fair point on the AI smell too

Converting to discussion since the README accuracy and tone are worth broader input.