What about keyword arguments?

[radanskoric]

Interesting project! One thing that I am wondering is how are keyword arguments handled? I can't find it in the documents, all of the examples seem to use just positional arguments. And trying to compile regular Ruby with keyword arguments of course treats the keyword values as types, since the syntax is the same.

For example, how can this code be expressed as T-Ruby?

def greet(name: "default")
  "Hello, #{name}!"
end

puts greet(name: "World")

[pvcresin]

It was implemented recently, wasn't it!

• feat: implement keyword arguments syntax #27

[radanskoric]

Ah, ok, that's cool.

If I'm reading it right, then my example would be written in T-Ruby as:

def greet({name: String == "default"})
  "Hello, #{name}!"
end

puts greet(name: "World")

Right?

[pvcresin]

It seemed slightly different. This is probably it.

# trb
def greet({ name: String = "default" }): String
  "Hello, #{name}!"
end

puts greet(name: "World")

↓

# rb
def greet(name: "default")
  "Hello, #{name}!"
end

puts greet(name: "World")

[radanskoric]

Thanks, glad this is now supported. 👍

It does kind of open a question of whether we can still say that all Ruby code is also T-Ruby code. It technically is, but if it has keyword arguments, it will work differently if it is not rewritten. But that's a separate question and I think it's also unavoidable with the chosen syntax.

[pvcresin]

That's right. I was also concerned about that point and have tried suggesting other syntaxes.

• [Enhancement] Distinguish keyword arguments from type annotations #19 (comment)

I think the fact that JavaScript code is always valid as TypeScript code has helped promote TypeScript's adoption, so this might be a major turning point.
On the other hand, I can understand that it's difficult to create a new language that supports all expressive Ruby code, so it might be unavoidable.

[radanskoric]

There is an inherent problem here with how flexible Ruby is. Personally I'd prefer your proposed syntax because it would still be true that: "You can just rename Ruby code to T-Ruby and it will work the same, and then you can add types gradually." That's no longer true if you use keyword arguments, which is very common.

However, it's very likely that eventually something else would force this difference, just because of how flexible Ruby is.

Time will tell if this causes T-Ruby to eventually go down the road that Crystal took and become its own language with "syntax inspired by Ruby" rather than being fully compatible with Ruby.

[yhk1038]

I've reopened this topic because it's still worth discussing.

I actually quite liked my syntactic solution for keyword arguments.
However, the proposition that "All Ruby code is T-Ruby code" was a bit of a slogan for me. (Special Thanks to @pvcresin)

I now agree that the current solution is potentially flawed, and I believe there needs to be more discussion about new ideas for syntactic improvements.

[yhk1038]

About Option 4

# what If original ruby code goes .rb -> .trb without static type
def foo(positional        , user_class:         User)    # .rb
def foo(positional        , user_class:         User)    # .trb

User may be misinterpreted as a static type.
However, User must be a live Ruby class object at runtime.
I think this needs some improvement.

[pvcresin]

As an alternative approach, I was also considering the case where we give up on "All Ruby code is T-Ruby code."
It might be good to have a command to convert code.

$ t-ruby --convert app.rb # convert to app.trb

# app.rb
def greet(name: "default")
  "Hello, #{name}!"
end

# app.trb
def greet({ name = "default" }) # convert T-Ruby code
  "Hello, #{name}!"
end

The idea is to convert to T-Ruby code by making minimal changes, such as for keyword arguments.

[pvcresin]

This would change the syntax for both positional arguments and keyword arguments.
How about a syntax like this?

Option 5. positional Type + keyword: Type:

def foo(positional String = 'default', keyword: String: "default")
def foo(positional        = 'default', keyword:         "default")
def foo(positional String            , keyword: String:          )
def foo(positional                   , keyword:                  )

• Keyword argument types have a : appended to the right (same as Option 4)
• A space is placed between the argument name and type for consistency
• For unions, I'm torn between keyword: (String | Integer): and keyword: String | Integer:.

Option 6. positional : Type + keyword: : Type

def foo(positional : String = 'default', keyword: : String "default")
def foo(positional          = 'default', keyword:          "default")
def foo(positional : String            , keyword: : String          )
def foo(positional                     , keyword:                   )

• Type is written as : Type after the argument name (somewhat similar to Crystal language coding style)
• If we consider the colon at the end of keyword arguments as part of the argument name, it creates consistency between regular arguments and keyword arguments.
• It's somewhat close to the current positional argument syntax.

[yhk1038]

In options 1~6, The option 1 and 6 are the best in my opinion. (but to be honest, I don't love them. They look a bit weird.)

And also, t-ruby convert option which is mentioned is bit of attractive for this struggle problem.

Let's keep gathering more ideas anyway.

[kimdj2]

I've been following this discussion with interest
I believe it would be better for the future direction of this project to cleanly abandon the 'All Ruby is T-Ruby' principal.😢

Crystal fundamentally differs in direction as it attempts to be a statically compiled language with Ruby syntax.
On the other hand, I think the ideal vision for T-Ruby is 'All T-Ruby compiles to Ruby', prioritizing seamless integration with the existing Ruby ecosystem.

I’ve looked at Options 1 through 6, but I can't shake the feeling that they all look a bit unnatural.
Personally, I think adopting the destructuring syntax (the {} approach) is the best path forward, especially if we seriously consider the migration tool suggested by @pvcresin to handle the transition

#32 (reply in thread)

[yhk1038]

Ruby → T-Ruby Compatibility Test Cases

When considering the "All Ruby code is T-Ruby code" principle, we need to ensure that valid Ruby code behaves identically in T-Ruby. Here are the key test cases that should be validated:

# test_ruby_compatibility.rb

module Compatibility
  String = "constant"  # Constant with same name as class

  # 1. Keyword default value is a class name (most dangerous case)
  def self.create(format: String, type: Integer)
  end

  # 2. All parameter types combined
  def self.process(x, *args, name:, retries: 3, **opts, &block)
  end

  # 3. Hash literal - value is class name
  TYPES = { string: String, integer: Integer }

  # 4. Method call - keyword argument with class value
  def self.run
    create(format: String, type: Integer)
  end

  # 5. Pattern matching (Ruby 3.0+)
  def self.match(obj)
    case obj
    in { name: String => n }
      n
    end
  end

  # 6. Lambda with keyword parameter
  TRANSFORM = ->(x, default: nil) { x || default }

  # 7. Heredoc containing type-like text
  QUERY = <<~SQL
    SELECT name: String FROM users
  SQL
end

Test Matrix

#	Unique Risk Factor	Location
1	Method def - keyword default = class name	create
2	Method def - parameter type distinction	process
3	Hash literal - key: ClassName	TYPES
4	Method call - key: ClassName	run
5	Pattern matching - key: ClassName	match
6	Lambda - keyword parameter	TRANSFORM
7	String content - should be excluded from parsing	QUERY

Core Issue: key: ClassName Pattern

All risky cases converge on the key: ClassName pattern:

Context	Ruby Meaning	T-Ruby Misinterpretation Risk
Method definition	Default value	Type annotation
Method call	Argument value	?
Hash literal	Value	?
Pattern matching	Type check	?

The key question is: How well can the parser distinguish context?

Any alternative syntax (Options 3-6) should pass all these test cases to maintain Ruby compatibility.