On Tue, Nov 5, 2013 at 7:43 PM, Chris Cain <clcain@uncg.edu> wrote:

On Wednesday, 6 November 2013 at 02:38:57 UTC, Timothee Cour wrote:

I agree. For that suggest the following syntax (independent of this
proposal):

That is, support UDA for expressions.

----
void main(){
import std.conv:text;

int var=12;

@("syntax=python")
r{
...snip...
}
}
----

I'd very nearly say that this could be a library function. Imagine it like this:

---
syntax!"python"(r{
...
})
---

A bit more verbose than using a UDA but the return type could be something like SyntaxType!"python" and you could make it so that functions only take SyntaxType!"python" for some compile-time checking using the type system. For instance, if your function requires python code then you can specify it in the argument. I'd also like it to be implicitly convertable to a generic SyntaxType that accepts everything if you just don't care what kind of syntax it is.

As long as it's part of the standard library, then IDEs could also take advantage of it. Not saying that they shouldn't also support UDAs, but just throwing that out there as another alternative.

one problem with this:

r{...} is converted to a built-in tuple, and we can't return built-in tuples from functions (only std.typecons.tuple, which has issues, eg unnecessary copying, can't return elements by ref, etc). Note that returning elements by ref (when needed) is crucial for use case B in the OT (formattedRead).

On the otherhand, I also thought about using a modification of std.typetuple.Alias that gets an extra 1st argument to indicate syntax.

It doesn't work because when there's an expression involved we get: Error: variable a cannot be read at compile time; eg: Alias!(a+b,"foo")

and r{...} syntax is suppose to support arbitrary expressions and forward them as builtin tuple.