Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Remove void "type"; convert statements to expressions

Open
#56 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
java
Domain
compilers

Research direction

No files, tests, or entry points are named. Start by reviewing the compiler's handling of void return types and statements, then define the language semantics and tests needed for fluent mutation, boolean procedure results, and expression-valued definitions before implementation.

Written by the indexing model from the issue text.

Description

proposal

Perhaps we should remove the use of void as a return type. Objects that perform an operation that modify themselves and don't necessarily have something to return can return themselves (similar to the builder pattern).

Example:

aList = [].add(1).add(2).add(3)
print(aList) // [1, 2, 3]

Procedures that aren't related to a class can always return a boolean indicating success or failure. We can even make the lack of a return be considered a success.

Example:

procedure1() {
    a = 10
    b = 10
    c = a + b
    print(c)
}

procedure1() // prints: '20', returns true

procedure2() {
    number = readInt()
    
     // This if "statement" would also technically be an expression that returns a boolean in this proposal
    if (number % 2 != 0) {
        // This can also be an expression maybe?
        return false
    }
}

procedure2() // < 1 returns false; < 2 returns true

It might encourage chaining procedures together like so:

checkCondition1(args) && checkCondition2(args) && checkCondition3(args) && doGuardedProcedure(args)

This is possible in the current state of LJ, but it might be further encouraged if we default return types to boolean (is this something we want to encourage?).

Presumably function definitions and class definitions would now also be expressions if we were strict about "no statements" which would mean LJ has first-class functions (and potentially lambdas).

function1 = main() { println("Hello, world!" }

function1() // "Hello, world!"
main() // "Hello, world!

function2 = (arg1, arg2) { printf("%s, %s", arg1, arg2) }
function2("cats", "dogs") // "cats, dogs"

function3(otherFunction, arg1, arg2) {
    return otherFunction(arg1, arg2)
} 

function3(function2, "cats", "dogs") // "cats, dogs"

class1 = Dog { ...class stuff... }
dog1 = class1() // Returns a new Dog instance
dog2 = Dog() // Returns a new Dog instance

class2 = { ...class stuff... } // LJ uses '{ }' for sets, so there needs to be some disambiguation here
object1 = class2()

someFactoryFunction(someClass, args) {
    return someClass(args)
}

someFactoryFunction(class1, args) // Returns a new Dog instance

Treating everything like an expression feels more clear. It might seem odd to beginners that some funny words "return" stuff while other funny words "do" stuff. Some beginners have trouble figuring out when to use print() and when to use a return for example.

Dominant language
Java
Stars
6
Forks
7
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from JMU-CS/less-java

All issues in JMU-CS/less-java

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.