re.captures by itself can reference a struct field, but not a method (because that would be an incomplete type). You might think of it as Regex::captures(&re) or something like this, which is nonsensical because it is missing an argument! The only "partial functions" in Rust are closures.
In the other case, String::from is a function pointer, much like Regex::captures.
For a more concrete description, the Rust Reference indicates that re.captures (referring to a method) isn't even supported by the parser:
The general consensus looks like it's just not worth it in a language built so very differently from Haskell.
But you may ask there again what they think about that idea. Using dot for currying certainly makes some sense, maybe someone there would explain why your idea is not good or maybe even adopt it if it would be deemed good enough.
The one that comes to mind is that you can't call a field using re.field() either. You have to (re.field)() for that. As such, parse-time can tell which is happening.
iter.map(re.bla) doesn't indicate that it's supposed to be a method call instead of field access -- after all, iter.step_by(re.blah) should be a field, not a method, since it wants a usize.
Lack of currying is a fair explanation for this, but Python doesn't have currying either and they managed to get around this problem:
class MyClass:
def __init__(self, a):
self.a = a
def my_method(self, n: int) -> int:
return self.a + n
if __name__ == '__main__':
c = MyClass(10)
xs = list(map(c.my_method, [1, 2, 3, 4, 5]))
print(xs)
print(c.my_method)
kamov@msi:~/Desktop$ python ./main.py
[11, 12, 13, 14, 15]
<bound method MyClass.my_method of <__main__.MyClass object at 0x7f9726290af0>>
This works, because methods in Python are a special type of functions which are bound to the object they come from, so they get automatically converted to the uncurried form by the Python interpreter. I'm not sure how feasible that would be though in Rust